jQuery together with other JS libraries (e.g. Prototype)

I want to gradually migrate from Prototype to JQuery in one of my projects (grails 2.0.4), but when I tried to use both libraries at the same time I got some error messages and the JS functions did not work anymore. Turns out JQuery has a compatibility feature you can turn on: http://docs.jquery.com/Using_jQuery_with_Other_Libraries jQuery.noConflict() On top of that there were issues with the resources plugin, which I circumvented for now by manually loading jQuery where I need it.

grails database migration plugin: upgrading an existing database

Today was in fact the first time I ever got into a situation where the setting dbCreate = 'update' couldn't manage to update my data base scheme after modifying some of my domain classes. This was unfortunate of course, but since I've been reading that this is bad practice anyway I decided to have a closer look at the new database migration plugin that came out at roughly the same time as grails 2.0 did. This plugin utilizes Liquibase, which has been around for a while from what I could see and seemingly does a very good job. It turns out that the database migration plugin gives you a really smooth integration of Liquibase and grails.

Coming to my actual problem:
After adding the spring-security plugin I wanted to have some light history with two of my domain classes, so I introduced the fields

• createdBy,
• lastUpdatedBy,
• created,
• lastUpdated.

The latter two are automagically populated by GORM and the first two I could populate in the controller classes using the springSecurityService. This obviously leaves existing database rows without this information and since I assigned a "not nullable" constraint, hibernate sure enough complaint when trying to change the scheme.

So I did some reading on the excellent tutorials I found to get up to speed:
http://blog.springsource.org/2011/08/17/countdown-to-grails-2-0-database-migrations/
http://fbflex.wordpress.com/2011/01/19/working-with-the-grails-database-migration-plugin/

After understanding the key concepts I went ahead and followed the instructions at the end of the second blog post (updating an existing database). I created a new environment "migrate" which I configured to use a copy of my database. My domain classes where already changed, so I just needed to compare the current database scheme with my domain classes using

This yields a changelog.groovy file that translates the liquibase xml configuration into the groovy world. Since the conversion is straight-forward you can make use of the liquibase docs to modify this changelog. The original changelog corresponds exactly to what GORM would have done anyway with dbCreate="update".

You can try and run it using the dbm-update command:
You might be happy at first seeing that everything seems to work fine, but soon you'll be frustrated because nothing actually happened. At this point you might have already asked yourself (like me) how the plugin knows which changelog you want to apply. And in fact you have to specify this in Config.groovy: Of course running the update failed for me. I didn't do anything about the not null constraint. I solved this problem by removing the constraint from the original add column configSet and adding a new configSet add the end where I specified a defaultNullValue ( http://www.liquibase.org/manual/add_not-null_constraint ), which replaces all my trouble-causing NULL entries with a sensible value: This worked really fine for the createdBy and lastUpdatedBy column where I only had to set an integer value. However, it took me quite some time to figure out how to set a date correctly. I read a lot about timestamp and getdate() functions and in the end the simplest solution was to just figure out the date syntax which looks like this:

 A few important tips for working with this plugin:

• Use grails -Dgrails.env=yourEnv to run a custom environment besides dev, test or prod.
• Use grails dbm-update-sql to see what SQL code is created.
• Be aware: The dbm-update command often fails more or less silently. Therefore: 
• Look into your database! There is a new table called DATABASECHANGELOG. 
If you compare the entries in this table you will quickly see which configSet caused the operation to fail. This is most likely due to a syntax error because problems with the database usually cause an exception.

And if you finally get to see the following line:


| Finished dbm-update

You finally did it and you can leave for the week-end. 

Select from a map in GSP?

Logging in grails 1.3.7

Logging capabilities haven improved a lot in grails 2.0, but my main project is still running on grails 1.3.7 and somehow I never managed to get any of the profiling plugins to work. I was suspecting that my application made a lot of repetitive and unnecessary requests to the SQL database so I needed a way to figure out what was happening between hibernate and the JDBC connection. Hibernate comes with its own logging but unfortunately it doesn't tell you anything about the response time of the database. So I was digging google and found this very promising approach on http://piraguaconsulting.blogspot.com/2010/06/grails-p6spy-and-sql-profiler.html, where p6spy basically replaces your database driver with a shadow version that logs all communication. Unfortunately this didn't work for my project. I use a C3P0 connection pool and the shadow driver of p6spy can't handle that (at least not as far as I could see). A pity since it seemed to be a good idea especially in combination with http://sourceforge.net/projects/sqlprofiler/ which combines the logging with a nice GUI.

However, this approach gave me a basic idea of what I was looking for and googling deeper I found http://code.google.com/p/log4jdbc/ which in contrast to p6spy is actively developed. Hooking it up with grails is super easy. You add the lib file to your project, exchange the database driver in your dataSource config with

net.sf.log4jdbc.DriverSpy

and adjust your database url:

Before:
jdbc:sqlserver://localhost:1433;databaseName=olabdb;

After:
jdbc:log4jdbc:sqlserver://localhost:1433;databaseName=olabdb;

Simple as that. The shadow driver of log4jdbc seems to recognize the most common SQL drivers and includes them without any effort from my side.

In order to turn logging on you add 'jdbc.sqltiming' to you log4j config in Config.groovy, e.g.
Log4j config is also explained here: http://grails.org/doc/latest/guide/conf.html#logging

Now it already works and gives you a nice and informative output including the parameters that are actually part of the SQL query. This helps a lot to learn how your domain model is reflected in the SQL world.


2012-03-08 10:58:10,515 [http-8080-5] INFO  jdbc.sqltiming  - select genes0_.recombinant_genes_id as recombin1_0_, genes0_.gene_id as gene2_0_ from gtRecombinant_gtGene
genes0_ where genes0_.recombinant_genes_id=977


My lesson was that inheritance is actually a bad thing since it causes multiple joins for each query that you do on a child class. Another thing I don't like is how hard it is to read the statements since all column names are referred to by a different name. A little more digging and I found this really nice post:

http://softdevbuilttolast.wordpress.com/2010/02/22/hibernate-sql-logging-log4jdbc-haciendo-log-de-sql-con-hibernate-log4jdbc/

It teaches you how to configure log4jdbc efficiently and to tailor it towards your needs. In my case I added a few starting parameters to my VM:

-Dlog4jdbc.debug.stack.prefix=org.openlab

This one allows you to specify your applications main package, which in turn allows log4jdbc to see where your own code begins. As a result it tells you which line of code caused the SQL query. SUPER NICE. Note that it only seems to work on log level 'all'.

Among hundreds of queries you want to see the "bad guys" that just take too long. You can set time thresholds for log.warn and log.error via

-Dlog4jdbc.sqltiming.warn.threshold=200
-Dlog4jdbc.sqltiming.error.threshold=1000

IDEA 11 and grails 1.3.7 / 2.0

Last week I gave IntelliJIDEA a shot at grails since we now have both, a new version of grails (2.0) and IDEA (11) which has a reputation for good grails support in the ultimate edition. Creating a new grails project with grails 2.0 was no problem at all. Although you have to inconveniently download and extract grails yourself, everything else works like a charm. IDEA has very good in-build support for grails, meaning you can install plugins via IDE etc. It provides a dedicated grails view for your projects and thus is offering kind of the same support as Springsource's own IDE called STS. A feature for building different kinds of grails classes is also given. What I particularly like is that you can create controller, views and tests directly via buttons offered on top of the domain class editor view. Just great :-)

But so far we haven't seen anything worth what Jetbrains charge for their software. This only becomes apparent if you use it for a little while. In the process you'll learn that code completion is by far superior to STS. IDEA always knows exactly what your domain classes look like and offers the right completion for dynamic finders à la findAllBy*. Cool stuff, but most convincing to me is actually the very good reaction time of IDEA compared to STS with mostly sluggish behaviour and an auto-update function that never worked for me. Bottom line for me was that I know decided to switch to IDEA.

For people moving from STS to IDEA, another thing will be most important. How difficult is it to move existing grails projects to IDEA? I mainly work on one project upgraded to grails 1.3.7 that involves a number of inplace-plugins. I told IDEA to create a new project from existing sources, selected the encompassing folder of all my projects and clicked next. IDEA recognized all my projects as grails/groovy projects, so I just had to select grails. Next, it asked for the SDK to use. Instead of using the 2.0 grails I added a new SDK pointing to the grails 1.3.7 folder of STS. After that, IDEA recognized all my plugins correctly (my former projects are now modules) and my application works out of the box with a normal startup (mainly thanks to using the same grails installation that already has downloaded all the necessary plugins). I was astonished how well that actually went :-)