Grails,Teradata and TIME/TIMESTAMP fields

Hi there,

For a long, long time I've been searching for a solution to the incompatibility issue between Teradata server and Teradata JDBC driver in regard to TIME/TIMESTAMP fields. I've finally figured out what's the deal :)

Long story short the database has columns defined as TIME(0) and TIMESTAMP(0) which during updates from Grails (especially the lastUpdated field filled in automagically) causes a number of different errors to come back from the server (5404 for example).

The problem is that java.lang.Date instances are translated using a default precision (which is grater than zero) and the database server is dumb enough to throw an error and not truncate the incoming data.

Solution: update to the latest version of JDBC driver (tested with TeraJDBC 13.10.00.01) and add TSNANO=0,TNANO=0 to connection string and live is good again!

I hope you'll find this solution handy :)

And by all means: have fun!

Grails 1.3.4 Released!

Hi there all you Grails geeks!

Yesterday Grails 1.3.4 was released :) Finally some bugs (described in my previous post) were fixed along with one small addition from me.

If you had a domain class that had a generator of type "assigned" and wanted to mockDomain that class then all calls to "save" method were treated as updates. The reason for that was that the distinction was made on the value of "id" field which had to be assigned in case of the "assigned" generator.

So I've proposed a fix for that that'll make the mocked version of save be sensitive to the actual generator type and if it's the "assigned" generator then to act smart instead :)

I hope you'll like it!

Grails 1.3.3 - testing domain classes FIX

Hi there,

if you're following the TDD principles while using Grails you might be very surprised when upgrading to Grails 1.3.3 because all your unit tests that mocked domain classes and utilized the "save()" instance method all of the sudden fail with some crazy message:

java.lang.NullPointerException
at grails.test.MockUtils.mockDomain(MockUtils.groovy:443)
at grails.test.MockUtils$mockDomain.call(Unknown Source)
at grails.test.GrailsUnitTestCase.mockDomain(GrailsUnitTestCase.groovy:131)
at grails.test.GrailsUnitTestCase.mockDomain(GrailsUnitTestCase.groovy:129)

It's obviously a bug, but don't fear - help is coming!

The bug description in Jira GRAILS-6482 has the answer!

I've allowed myself to go one step further and I've created a base class for those cases where it's needed (DRY - remember?)

package grails.test

import org.codehaus.groovy.grails.plugins.GrailsPluginManager
import org.codehaus.groovy.grails.plugins.PluginManagerHolder

class FixedGrailsUnitTestCase extends GrailsUnitTestCase {

    protected void setUp() {
        super.setUp();
        PluginManagerHolder.pluginManager = [
                hasGrailsPlugin: { String name -> true }
        ] as GrailsPluginManager
    }

    protected void tearDown() {
        super.tearDown();
        PluginManagerHolder.pluginManager = null
    }
}

Now all my test classes that were touched by this issue inherit from FixedGrailsUnitTestCase and life is good again :)

I hope this will spare you a few minutes :)

Grails and content negotiation

Hi all,

I've been going through the user's manual for Grails and was shocked that this little piece has slipped my study before. Content negotiation is done in Grails in the most simple and user-friendly way and above all it's almost identical to Ruby on Rails!

I've recently blogged on how to achieve a similar result using ASP.NET MVC (which does require certain amount of manual work)

In Grails everything you need is already built-in. The engine recognizes extensions passed on in the URL automatically as well as request headers (if properly specified by client) and the "withFormat" construct resembles 100% its counterpart in RoR.

The longer I use and study Grails the more I see the power behind it. Even though it might be unstable from version to version (especially the major ones) it's still one of the most comprehensive, well designed and user-friendly web application platforms ever created. I love it!

Have fun!

ICEfaces 1.8 - Next Generation Enterprise Web Development

Hi,

because of the integration of ICEfaces and Grails I started looking at books describing ICEfaces as a framework. Unfortunately I found only one, the "ICEfaces 1.8 - Next Generation Enterprise Web Development".

I was pretty excited at first when I saw the integration itself. Many things are done by convention (so more/less the Grails way), views use Facelts for templating... And in many places ICEfaces is mentioned as the best JSF-based framework out there.

So back to me reading the book...

Well,... hm,... what can I say...

60 pages of blah blah blah about how difficult it was to create web applications in the past with pure servlets and JSP, then the magical discovery that was made that web apps could actually mimic the experience of desktop apps... All nice and dandy but... BOOOORING!!!

I finally came to the page where code started to shine through the misery we've been at for the past decade or so. The thing that killed me at first was the statement that layouts should be done using tables!

I mean come on, guys! Where's the distinction between content and presentation? Where's the semantic web stuff??? Should we abandon CSS completely because IE is so damn cruel in this regard?

They even say that they took this road because of "pragmatism":

You may wonder why we use a <table> for the layout, and even the align attribute, when there is a <div> tag and CSS. The answer is pragmatism.

Whatta heck is that?

Honestly, around page 64 I have decided to stop reading the 290+ pages miserable poem and figure out the way to deal with ICEfaces myself using examples from their website.

The conclusion is that some books could just be better. Nonetheless it's fascinating how things get boring when you step back into the "official enterprise" sort of things having your brain already set on the nature of the web (the request/response kind of thing) by all those MVC-based frameworks like Grails, RoR and ASP.NET MVC...

Have fun!

C# with dynamic: Xml processing

Hi there!

I've been watching Anders Hejlsberg and his presentation about dynamic features introduced in C# 4.0. It got me into thinking that the CTPs and RCs of the language must have been long enough out there for people to do some crazy stuff with it.

I was sooo not mistaken!

Take a look at those couple of things here:

1. DynamicXmlParser
2. XmlBuilder

Those are like straight out of Groovy just named a bit differently (the dynamic xml parser is called XmlSlurper) but do mostly the same thing!

C# is getting more and more appealing to my liking of programming languages :)

Have fun!

Delphi 2010

Hi there!

I'm currently looking at the newest version of old Borland tools namely the "Delphi 2010" environment. I thought that I'll share my thoughts with the rest of you...

There are a few things I'd like to make one thing completely clear: I'm a seasoned Delphi programmer with more that 10 years of experience of using Borland's and then Inprise'es and after that CodeGear's tools to do the job. That being said it is my honor to write a brief review of the latest and the greatest that came out of Embarcadero...

So.. Leaving the "nice words" behind let's see what's in the package!

Let's start with Ruby.
The so called "3rd rail" is not much of a helper since all they have added is the project support, debugging and some code-insight (that's Borland's name for the code hints). After 15 minutes I've reverted back to the only free IDE supporting RoR and I was happy to stop dragging the 3rd leg behind me...

(I just needed to spit it out - sorry :D)

Delphi... Completely different story!
I was using Delphi from version 2.0 when it came out in 1996 I was still using Turbo Pascal and I believed that to be the ultimate choice for a developer. Delphi teached me that doing GUI manually might not be the best idea and also showed me that stuff like code insight are actually working.
Years after that (4 to be exact) I started working for a company in Poland that used Delphi 5 to do some CAE-like application. It was really amazing what one might have accomplished with this tool at hand!
Later we've switched to Delphi 7 which I believe to be the absolutely, completely, unquestionably best IDE in the world EVER! The personal edition had everything a proficient Pascal developer would ever need and was so damn fast that today's Express editions of Visual Studio can only dream about being in such a great shape.

Then came along Delphi 8... For Microsoft .NET 1.0 (as far as I can remember)... It came and went...

I really hoped Delphi 8 was a misunderstanding and that later version of my beloved IDE will follow the usual path. You can imagine how crushed I was when the next version came out and it was based on the same completely lame engine as 8!!! That was the day I thought to myself "OK buddy, it's time to learn something else". With that in mind I was still looking at the evolution of my old IDE just to make sure I made the right choice :)

Today it's the year 2010, Borland is pretty much dead, Inprise is a name no one has ever heard of, CodeGear has a nice ring to it but the phrase "whatta heck is it" surfaces every time I ask someone about it... And today's name for the company is..... Embarcadero!

They still follow that same devil's route Inprise embarked on in 2003 which is a long-starting, incredibly embedded, ugly looking and slow performing IDE.
Sure they have added some cool features to the language. No questions about it... But was that enough to justify a programming language evolution to bring the old, lovely platform down???

Today I'd never ever choose Delphi for my development - at least nothing above version 7 which is in my opinion the best IDE for Pascal-like languages ever created (and I admit I'm a bit tainted but hey.. who's not!).

I'd like to know why Borland and then Inprise, CodeGear and finally Embarcadero didn't see the beauty of the IDE, the language and the huge user base they have had back in the days and shifted to this ugly-looking thing they are feeding us today?


Rust in Peace Delphi! You'll always have a special place in my heart!