Back in June, someone hacked this site, and added a malware iframe.

I cleaned it up, upgraded Wordpress, and went on with my life, assuming that someone had just exploited a post.

Well, it was hacked again, the same way. Since I had upgraded Wordpress, I was more suspicious, and I delved into my website setup.

When I went to the User tab, I saw this:

Administrators(2)

(And I expected to only see one) But when I went to the adminstrators tab, I saw this:

Administrators(1)

hmmm. That’s suspicious. I looked at the page source, and sure enough, there were two entries, but the second one was buried in a morass of javascript and styles. Egads - someone has not only gained administrative access to my blog, but they have effectively prevented me from removing them via the website.

Luckily for me, I know enough about SQL to be dangerous, so I went into PhpMyAdmin and deleted all the other users except me. This worked because the only users were random bogus registrations trying to get around my spam filters.

I’ve since turned off new registrations, and I suggest everyone else do the following:

1. Check on your users - see if you have more administrators than you expect, and if so, delete them with extreme prejudice.
2. turn off new user registration

Bleah

I spent most of the last post talking about magic, but what I intended to talk about is the regular occurrence of the database getting out of sync with the domain objects in Grails.

In theory, based on using the Update directive in the database configuration, my database should be updated to match the domain objects. In my experience, however, Grails regularly fails to properly upgrade the database, and I’m forced to delete the whole thing in order to get the system sane again. This doesn’t happen all the time - generally only when I need to create a new relationship between tables or apply a new constraint (for example, allowing a column/field to be null).

Luckily, since I’m using Hypersonic SQL, this is straightforward. Shut down your grails app, and from your grails project top-level directory:

cd db
rm devDb.*      # or whatever the name of your database is

Then restart grails. It will regenerate the database (without data) with the latest constraints and structures you’ve made. You’ll need to repopulate, but there are tools for that.

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.

One of the interesting things I’ve had to work with on my Grails project is compilation.  Occasionally, I’ll get a .groovy file that seems to put Grails into an endless ‘compile-load-restart’ loop.   To discover which file is the culprit, I physically stop the server after the compilation, but before the restart, and then go into $HOME/.grails/<VERSION>/<Project_Name>/classes/  and look to see which file was most recently compiled.

This tells me a little about what’s going on, and I was able to remove the .groovy file in this case to stop the endless restarting.