informIT just started a new multiple-part tutorial on how to use Hibernate (the top dog in Java ORMs) to create a domain model for a small book shop. By the end of the second XML file, I was ready to cry for mercy. So I did and Active Record answered:
class Book < ActiveRecord::Base
belongs_to :publisher
has_and_belongs_to_many :authors
end
class Publisher < ActiveRecord::Base
has_many :books
end
class Author < ActiveRecord::Base
has_and_belongs_to_many :books
end
Whups. I think we just got ahead of ourselves. The model above won't materialize in the Hibernate tutorial for another few installments. For the first one, they just got Book up and running.
But since it took all of five seconds to describe the domain (please note that were assuming the existence of a database schema, just like the Hibernate tutorial), let's give a few examples on its usage as well:
This is not pseudo-code. It's how most of the domain logic in Basecamp and other Rails applications work. Why does it how to be harder than this?
If you're ready to get outta dodge, please do have a look at Rails. It's a web-application framework that includes Active Record and its sister Action Pack. I wouldn't recommend it if you're trying to make a living as a tutorials writer and you're paid by the word, though.
What are the mechanisms in ActiveRecord that allow for 'mapping' into an existing schema? ActiveRecord does look great, but all of the examples i've seen so far are of the kind where you are starting from scratch, which gives you the freedom of designing your own schema. However, in many cases either you have to work with an existing schema, or have the schema design designed by a DBA, to which you then have to map your domain to. Hibernate makes these kinds of scenarios simple to deal with (if you consider editing XML files and creating the mappings simple that is :)).
I agree that ActiveRecord is awsome to use, but i also find it a little too close to the database. For example, what happens when schema changes occour? The complexity of Hibernate can shield you from this.
I'm not trying to put down ActiveRecord and make Hibernate look good or vice versa. I think they are both great frameworks. I'm just trying to understand ActiveRecord a bit more as I am very impressed with that I have seen so far.
Active Record is definitely geared towards new applications that has the freedom to design the database with non-business ID keys, proper foreign keys, and all the other hallmarks of a programmer-driven database design (vs a normalization/DBA one).
So that's where I see a clear advantage for Hibernate: Invigorate your crazy legacy database with a OOP shell. Active Record is certainly not aiming to storm the hill on that one.
That being said, it is actually possible to configure quiet a few things about the Active Record mapping. Like the name and type of the ID field, the table name that it's mapping up against, and more.
That's mostly to get people with strong feelings about whether table names should be in plural or singular on board with Active Record. Then when they've worked with the system for a while, they'll hopefully recognize that it's just easier to follow the preferred naming scheme and start to enjoy all the automation.
I call this "Conformity through freebies".
On schema changes: Why would you change your schema if you don't want the domain model to change with it? Outside the definition of new indexes (which Rails wouldn't care about), I can't come up with a good example (in the new app with App DB world).
Also, Rails is definitely geared towards the use of an Application Database rather than an Integration Database. Fowler has a good article on the differences.
Challenge by jc on September 04, 17:22
David,
Thanks for the prompt reply!
I understand the differences between Application Database and Integration Database, and now understand better where ActiveRecord fits in.
Challenge by Florian Weber on September 04, 17:25
i think basically it all comes down to one thing:
hibernate doesn't assume anything, its very flexible, so you have to specify everything you want it to do/know.
for so many cases though you don't need/want that flexibility. the per default assumption would work great.. and you rather specify the small things which differ from it, than specifying
everything from the ground up.
Challenge by Nathan on September 05, 6:53
Dude... relentless. Absolutely relentless.
I love it!
Challenge by on September 08, 16:56
Hibernate may look complicated but compared to other ORM technologies in Java it is simple and elegant (Have a look at an EJB persistance tutorial and then complain).
Oh, I think Hibernate is a marvelous piece of framework. I loved the book that Gavin and company wrote on it. Lots and lots of good ideas and a strong intellectual concept.
It's just that I find the "everything must be configured from scratch" approach to be way, way to laborious for my liking. All those configuration files and Java on top is just too much (for me).
David, I'm glad you have acknowledged Hibernate's "goodness".
The example you have given of using ActiveRecord is obviously trivial compared with many enterprise applications. And I'm sure you would acknowledge Hibernate's power as an ORM.
What limitations do you see with Active Record? For example, how does it handle mapping class inheritance and polymorphic associations?
Active Record is clearly most suitable for new application development. Hibernate has much more flexibility to allow mapping of legacy database systems with peculiar table definitions, so that's probably the most obvious limitation.
Active Record handles inheritance using Single Table Inheritance and polymorphic associations works just as you would think (has_many :people can return Person, Employee, or Manager as the type dictates).
Also, the example wasn't of my choosing. I just followed the domain as it was picked in the Hibernate tutorial.
Sorry to be a late bird, but I'll have to bring still another Rails newbie opinion in play.
jc,
I don't quite see the problem of using an existing schema. If you take a look at the tutorial on Rails homepage, you can see that you can first design the schema and ActiveRecord then does the mapping automatically. I don't know why it would matter if the schema is created by you two minutes ago or by a DBA last year.
As for schema changes, I think that's where ruby as a dynamic language and ActiveRecord especially shine. If you change the schema (e.g. add field to a table), the AR object reflects that change automatically since AR builds the class dynamically. You can take that as a con (but, as David said, there's not many circumstances where you'd want to not reflect a schema change in the domain), or, like I do, a major productivity booster.
Of course there are changes that also need to be reflected in AR, most notably new associations. But the only thing that's needed is to say something like belongs_to :otherclass in the class definitions. That's far from repeating everything in an XML file.
OK, I don't want to ditch Hibernate in any way since I don't know much about it, and my experience even with ActiveRecord is very limited. But saying "inflexible" and "ActiveRecord" in the same sentence... nah, it really doesn't fit in with my experiences so far.
