Lambda the Ultimate

If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table)

Now, is Rails that smart, or would that need to be a Persons table?

The beauty of specifying relationships with belongs_to, has_one, has_many and has_and_belongs_to_many.
It's small but my asp.net code automatically picks up on relationships (excepting many-to-many, which I'm not entirely sure would be possible to infer properly). That rails doesn't do this is probably due to MySQL which has very shaky (and only recent) support for referential integrity. Granted, it can use PostgreSQL but it was designed on MySQL (I assume) so this kind of stuck around.

I love Rails. Hopefully in a few years time we'll look at it as the first stage of a breakthrough in web development, leaving all that irritating J2EE crap behind and allowing people to use powerful languages and functional programming techniques to do everyday web-based database work.

I do have a few beefs with ActiveRecord though. While it is very useful, I find myself frustrated by some of its limitations. It can't deal with multi-column primary keys, infact (as I recall) it requires that the primary key is a single integer auto_increment column. It won't auto-detect foreign keys, and when you want to do complex queries with lots of joins you end up having to pass it bits of join SQL as text.

If anyone's interested, I am actually working on an alternative to ActiveRecord called ActiveRelation, which aims to provide full(er) support for the relational model within the confines of a Ruby-based ORM tool. It's geared very much towards providing a clean Ruby-style syntax for querying and working with a relational database, rather than being a database-backed persistance mechanism for existing Objects. (ActiveRecord can't seem to make up its mind which of these two it wants to be, although it does swing more towards the former).

My ActiveRelation will inspect the database to find all tables with their primary keys and foreign keys, and places no restrictions on your DB schema. It also has a powerful syntax-building system for the relational algebra, allowing you to build up syntax trees for arbitrary queries, which can then be used as iterators to fetch the results in friendly ORM-style object wrappers. The ORM features are built over the top of the relational algebra stuff, rather than joins and so on being added as an afterthought to the ORM code.

It can often 'guess' how to join tables given what it knows about foreign keys, so you can do things like this:

Location.select(Location.name == 'London').join(Artist).join(Label).project(Label).each {|label| puts label.name }

It also provides friendly get and set methods for foreign keys automatically, like so:

a = Artist.get_by_primary_key(1234)
puts a.link.url
puts a.label.location.name
a.link = Link.new! :url => 'http://foo/', :name => 'Foo'

It also comes with some helper methods which let you tell it about many-to-many relationships and tree structures.

Neat huh? Only disadvantage is that it currently only works with MySQL. But that could easily be changed if I had the time. It could also benefit from a bit of optimisation and clean-up. Let me know if you're interested in trying it out though, I intend to GPL it at some stage.

"leaving all that irritating J2EE crap behind and allowing people to use powerful languages and functional programming techniques to do everyday web-based database work"

Amen brother!

And I say that as a professional Java developer.

I find most Java developers want nothing to do with new languages. For some reason they think Java is the best programming language in the universe and they don't want some new language coming along and stealing the show.

I loathe J2EE, but I don't see it going away any time soon. The mass of beurocracy it imposes makes it possible for large teams of folks to work on projects together. Maybe there's a conservation theorem at work: the cooler the language, the more hacker-friendly, the worse the language, the more big-company friendly? But that's pro'lly for another article.

I'm working on my own language to run in the JVM (mostly Haskell inspired), but I'm planning on stealing whatever I can from Rails, and shamelessly so.

Rails has inspired some the most rewarding web development I've done to date, but I also don't agree with its default use of MySQL. While the table associations are substantially easier to configure in Rails over J2EE, it really should be taken a step further and be done automatically. For that and plenty of other reasons, I would much rather have Rails built around Postgres.

While I agree with the general idea of something like Rails, I find this particular implementation of it to be pretty poor.

The first thing that bit me was the pluralization thing, because I and my co-workers use the naming convention that you name a table after what a row in it represents. I don't mind if rails makes "person/people" easy for those that use that convenetion, but why make it harder for those who want a table called "person"? In the end, I find myself having to guess, "what will Rails do with this word?" (Ruby in general often has this problem that you can't predict with confidence what it will do in a given situation, because it tries to do someone's definition of the "right" thing rather than the obvious and simple thing.)

But stuff like subclassing an ActiveRecord class invoking the Single Table Inheritance design pattern really takes the cake. I made a simple refactoring (Pull Up Method) in a couple of AR classes and suddenly everything goes all to hell. And I spent a long time trying to figure out how to turn off the behavior, time that convinced me that the AR parent classes know far more about their children than they ought to. That Single Table Inheritance is non-relational silliness was just icing on the cake, as it were.