«

»

Aug 08

Rails To Grails: Database Integration (Part 1)

In Rails, your domain model objects derive their structure and content from the database layout. In Grails, however, the database tables are created based on the fields and directives embedded in your .groovy files.

Of the two mechanisms, I find Grails’ approach to be more sensible for greenfield applications (i.e. no legacy database), and for legacy applications, it’s probably a wash, unless the database is already named in a Rails-friendly way.

I like the Grails approach because it does not violate the ‘Do No Magic’ directive.
What, pray tell, is the ‘Do No Magic’ directive?

Good question! Let’s consider a software thought experiment. You’re a novice programmer, and you’re assigned to work on an existing project. You understand the basics of software development, logging, etc, but you’re not an expert.

Your first job is to fix a bug. You have access to the source code, you know generally where the bug is, and you have log files that show the bug in action.

So you look at the source, and then look at the log files. Let’s say your source looks like this

    log.debug "About to do Step A"
    step_a()
    log.debug "Completed Step A"
    log.debug "Program Finished

And inside step_a() you see:

    def step_a() {
        log.debug "Starting Step A"
        // biz logic
        log.debug "Completing Step A"
    

But when you look at the log file, you see this:

1000 : About to do Step A
1001 : Completed Step A
1002 : Program Finished
1003 : Launching Thread
1005 : Activating Queue
1006 : ... other stuff...

How is this possible? Some of you may ask. My answer is – in this case – Aspects – which ‘intercepted’ step_a() and did something else instead.

But at no point in the code do you see the possibility of said interception. You have to know ahead of time that Aspects are running, in order to understand this code. To the uninitiated, this code is magic.

Rails has a similar problem – you have to look at the correct table in the database to discover how the domain objects are structured.    Again, to those who don’t know that Rails derives models from database columns, this is magic

Let’s not even speak of monkeypatching, which might more properly be called duck punching.

Hold Your Flamethrowers

To be clear: the use of database for domain objects in Rails is a relatively benign form of magic – it isn’t nearly as bad as aspect-injected  asynchronous thread launching and other such mischief.   But it is still more magical than Grails.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>