Just wondering if you still play around with Grails these days?
Peter

Query syntax is less problematic then you seem to suppose. Even without using find_by_sql, Rails has dynamic finder methods that will cover even fairly complex cases (you can do things like find_by_first_name_and_zip_code if you really need to, for example).

As far as entity names go, it's easy to use set_table_name and set_primary_key to tell Rails that the names of the table and primary key field are not what you'd think from the class name, so the only stumbling block is the attribute names. It's not well known, but a little digging unearthed the alias_attribute method, which allows you to easily create an alias for any attribute, so that you can do

class Customer < ActiveRecord::Base
set_table_name 'tbl_Customrz'
set_primary_key 'int_cust_id'

alias_attribute :name, :varchar_firstname_lastname
end

This will let you read and write to Customer#name. That leaves dynamic finder methods as the only real issue — in the current version (2.1.0), they don't appear to work with aliased attributes, but there's a patch at http://dev.rubyonrails.org/ticket/11354 that apparently fixes that problem (although I haven't tried it).

For one model made up of multiple tables, I would probably just create a DB view, or an abstraction layer of mediating objects. composed_of might come in handy here.

My point, then, is that Rails ActiveRecord does indeed have a suitable query language that can be uncoupled from the database. You don't hear much about it because Rails developers don't tend to use it that way, but it *does* exist.

The distiction is that with SQL you have to understand the tables and columns, while with HQL (for example) you have to understand your classes and properties. Maybe I've got some nasty mappings to a legacy schema, or I need to segment a single entity into three tables for performance, or my DBA's are crazy and insist that all tables start with "TBL_" and columns use Hungarian Notation. All of these things should be transparent to the application: that's the point of ORM. But by using SQL I'm forced to deal with them. Using HQL, which is above the ORM layer, ensures that all that garbage stays hidden from the application. This is a hugely powerful distinction that often doesn't make much of a case for itself in simple applications, particularly top-to-bottom one.

You also save yourself from any database-specific stuff, which I've found incredibly useful because I can use Hypersonic (a crazy fast, in-JVM, memory-only DB) for unit tests, but deploy to a real DB without having to care about dialect differences.

If I understand correctly what you mean by "business-model-centric way of querying", it should be possible to add that to your Rails models quite easily.

Also remember that Ruby classes are always open. It probably wouldn't be *that* difficult to extend Rails ActiveRecord to do Hibernate-style queries, although no one has done it so far as I can tell.

Or am I misunderstanding?

Groovy doesn't have any sort of ORM framework itself, though it does have a slick-seeming SQL interface. I haven't actually used it, so I can't say for sure though.

Grails uses Hibernate under the hood, so you have access to the full Hibernate stack, including HQL. I suppose picking up the dialect is a bit of work, but it's never been an issue for me, even when starting. More troubling is thinking in terms of querying objects, rather than tables. That's a conceptual hurdle that took me a while to get my head around (and I still sometimes butt up against). However it does allow a far more business-model-centric way of querying which is quite nice, as well as providing an abstraction layer that allows you to extend the query language in an application-specific (and DB neutral) way.

When I said ActiveRecord didn't have a query language, I was referring specifically to querying the conceptual object store to select instances. find_by_sql doesn't even come close to that: it's nothing more than a way to do raw SQL queries against the DB connection configured for ActiveRecord. It's really more analogous to getting a Connection object from Hibernate and doing SQL against it (using Groovy's SQL stuff, or plain JDBC).

Anyway, you said that ActiveRecord doesn't have a query language. If I understand correctly what you're getting at, that's not quite true, at least in the sense that you can pass native SQL code to ActiveRecord.find_by_sql . There's certainly nothing in Rails like EJBQL, but to my mind that's OK — who needs to learn yet another dialect of SQL?

How does Groovy deal with this? I've never worked with it, although my last job was with a company that created what as far as they knew was the largest Groovy project to date. But I wasn't working on that project.

Eight years ago, CF was awesome. It blew the pants off other languages available for developing web apps quickly and easily. These days, it's a far less compelling choice. I doubt it's market share has diminished, but I feel that it's relevance has.

I wasn't referring specifically to Grails as the reason for it; I've had that opinion for quite a while. There are a whole pile of web toolkits out there now, and they're breaking some cool new ground. I wouldn't care to use a number of them, but I do appreciate what they're doing. CF, on the other hand, has done little. CFC's were a step in the right direction, but the implementation is poor in many ways. Other than that, almost all improvements have just been reinventing the wheel with CFML syntax, and often in a very limited way (consider the mess that is CFTHREAD, or the breaking of CFMAIL when CFMAILPARAM was added).

I have no doubt that Groovy and/on Grails is an exciting track to go down but I am not sure that relates to CF being less relevant; just my opinion from indicators that I see. Thanks again.

I'm not going to call it either way, but Grails definitely provides a lot of stuff that a certain set of CF developers have been crying out for, and does it without requiring as large a shift as other alternatives. I haven't done it, but I see no reason that you couldn't easily build a hybrid CF/Groovy/Grails app, and with enormously less pain than CF/Java hybrids.

I know I'm going to be doing CF for a good while since Mentor's heavily entrenched. CF's relevance is definitely waning (regardless of Adobe's sales figures). Perhaps an influx of good ideas could buoy it.