I was thinking the exact same thing. My superficial reaction is that they could embed jruby in their java code and use the real active record model. this would let them reuse the validation logic and all that good stuff.
I'm really curious if they explored this possibility, and if so why they rejected it.
I immediately jumped to this conclusion as well. I judge that it may not have occurred to them. If most of their experience was in Java they may not have thought of embedding as a solution.
I think there is more to this story than is being told. They say:
"However, we evolved to need something more than Ruby."
Maybe they don't want to be seen as bashing Ruby and thus inciting a pointless language flamewar, but it would be interesting to know what problem or set of problems became the pebble in their shoe that eventually they couldn't stand it anymore.
'Evolved' kind of implies a smooth and natural progression, whereas swapping languages is often more ... abrupt.
Can anyone who's got Hibernate and ActiveRecord experience give a quick shot on the big differences?
I haven't used ActiveRecord.. but spent years with Hibernate, and consider it a pretty impecable project compared to other ORMs I've encountered (J2EE's CMP, and Django's ORM, specifically.
I've used NHibernate (which is the .NET port of Hibernate) and Rails ActiveRecord.
The biggest difference to me is that Rails ActiveRecord encourages you to work from the database first. That is, you define your database tables and columns which are then used to generate your classes. In contrast, NHibernate (and I'm assuming Hibernate as well) encourages you to design your classes first and worry about persistence later.
There are merits to both approaches. In general, I'd say that Rails ActiveRecord is much easier to use and get started with while NHibernate allows for more flexibility in your domain model.
from programming interface, the new Active Record Query Interface 3, is very similar to HIbernate Criteria API. I wish they could of been more specific on what issues they had with Hibernate. Other than that the comments about dynamic creation are correct. In Hibernate they try to create the idea that you're object model doesn't need to be a 1:1 model with your data model.
Oh! of course.. that's definitely a really good point. Hibernate's HQL.. Frankly, I never got much use of Hibernate's Criteria stuff.. was always a second class citizen compared to HQL, other than for certain use cases that really demanded dynamic query building.
Even Django's ORM runs circles around Criteria.. in fact, the API design of the Django stuff is the one thing that I think really shines about it..
remotely related: php-activerecord (https://github.com/kla/php-activerecord) is a good php implementation of activerecord that works pretty much like the ruby version.
no migration support yet, but the rest of the code is there. i've been using it in a number of projects for over a year.
To me the biggest benefit of ActiveRecord is the database introspection to dynamically create the objects attributes based on the columns in the database.
This doesn't do that in Java, it parses rails migrations to generate the java classes for objects with these attributes.
Why is this a problem?
We have a similar setup up where I work, but rails migrations doesn't manage the database schema, that is managed on the java side. Rails still gets all changes to the DB in its objects, but using this setup wouldn't work. I was all excited by the title too, still it's a good solution to their particular problem.
I remember tackling a similar database introspection problem in 2006 I think it was. Reflection played a pretty big part in the solution if I recall.
I don't remember what exactly it was that I wanted to do, but it might have been something like building a dynamic table editor. You pull back the resultset, and then whip up a grid and for each column you assign the column heading based on the value from the resultset, and then when you go to update one of the rows you need to remember the name of the column for building the query dynamically. You have to jump through a few hoops, but it isn't hard.
Anyway, once I discovered the superior technology of JPA I never looked back.
It doesn't use the Rails migrations -- it reads the schema from schema.rb, which is generated by `rake db:schema`. You usually don't run this directly as it happens whenever you run `rake db:migrate`, but it's not dependent on migrations.
