Help

In this article on JavaLobby, Daniel Spiewak, the creator of something called ActiveObjects takes some pot shots at Hibernate, and compares Hibernate negatively with Ruby's ActiveRecord and ActiveObjects. Now, I'm always interested to read informed criticism, but in this case, Daniel seems to be comparing these brand new frameworks against Hibernate2, released in 2003, before I joined JBoss. He says:

Think about it, when's the last time you tried to configure a Hibernate project from scratch? You have to write more XML than code!

Er. Last time I or most other users of Hibernate3 tried to configure a Hibernate project, the only XML they needed to write was the persistence.xml file, which contains basic database connection settings. If Daniel has discovered some magical means to automatically intuit the database that the user wants to connect to, without the user needing to type in the JDBC URL, I would just love to hear about it ;-)

Daniel goes on to claim:

We have a simple table which has a one-to-many relationship with another table. Each table has a few values and a primary key (id). Now in Hibernate, we would map to this schema using a pair of Java beans and mountains of mapping XML.

Of course, Hibernate Annotations has been around since early 2005 and there is no longer any good reason for people to define mappings in XML.

So, to solve this non-problem of mountains of XML, Daniel was inspired by Ruby's ActiveRecord. The code example he gives is the following:

class Person < ActiveRecord::Base  
   belongs_to :company  
end
class Company < ActiveRecord::Base  
   has_many :people  
end

At this point, most developers are thinking um, ok, so how the hell am I supposed to know what attributes a Company has by looking at my code? And how can my IDE auto-complete them? Of course, the Rails folks have a quick answer to this question Oh, just fire up your database client and look in the database!. Then, assuming that you know ActiveRecord's automagic capitalization and pluralization rules /perfectly/, you will be able to guess the names of the attributes of your own Company class, and type them in manually.

Somehow, excitement about the Ruby language has warped their perceptions to such an extent that these people actually believe that this is a /good thing/!

Fortunately, Daniel's product does not implement this absurd approach. In ActiveObjects, you /do/ have to list the attributes of Company. In ActiveObjects, our Company class looks like this:

public interface Company extends Entity {

   public String getName();  
   public void setName(String name);  
       
   public String getTickerSymbol();  
   public void setTickerSymbol(String tickerSymbol);  
       
   @OneToMany  
   public Person[] getPeople();

}

Oh, except that it's not a class at all :-/ So if I have methods that perform business logic, or validate internal constraints, I have nowhere to write the code! Now, this problem could in theory be solved by using an abstract class instead of an interface, and using a bytecode library like CGLIB to generate the implementation class. Unfortunately Daniel's product does not currently support that, since his implementation uses JDK dynamic proxies.

So, exactly what problem has ActiveObjects solved? Is writing the implementation of getName() and setName() /really/ reducing your project's productivity? C'mon, my IDE can do it with a single keyboard shortcut! The equivalent code in Hibernate or any other JPA implementation looks like this:

@Entity
public class Company extends Entity {  
   private String name;  
   private String tickerSymbol;
   @OneToMany private Person[] people;

   public void getName() { return name; }  
   public void setName(String name) { this.name = name; }

   public void getTickerSymbol() { return tickerSymbol; }      
   public void setTickerSymbol(String tickerSymbol) { this.tickerSymbol = tickerSymbol; }

   public Person[] getPeople() { return people; }
   public void setPeople(Person[] people) { this.people = people; }

}

(Where Entity is some class I wrote that defines the id attribute.)

Note that I did not need to write any XML, let alone mountains of the stuff.

I really don't think this code is significantly more complex or difficult to type than the ActiveObjects version (in fact, in a modern IDE, it probably requires /fewer/ keystrokes to produce). Even better, I don't need to use any funny API to instantiate this class. I can just use new and be done with it.

And I think the code is a lot clearer and more explicit than the ActiveRecord version. Object orientation was very much intended for modeling business domain objects like Company and Person. It seems more than strange that Rails would essentially delegate the business domain model to the database.

Update:

Emmanuel just noticed that on this page it is claimed that:

AO also has the potential to have significantly superior performance to more traditional ORMs such as Hibernate because it is lazy-loaded with a multi-tiered caching system.

Curious. Hibernate has had lazy loading and a multi-layered caching system since 1.x versions. I wonder if Daniel has ever actually /used/ Hibernate?

38 comments:
 
19. Sep 2007, 03:43 CET | Link

Hey Gavin,

You're absolutely right about the false criticisms of hibernate requiring gobs of XML, annotations solved that problem rather elegantly years ago. But as a Java developer that converted over to Ruby on Rails, I would say that the I can't see the attributes of my objects in my model class problem isn't even a big deal. You either use the Annotate Models plugin or just look in the database. It's a small price to pay for benefit of using such a powerful language. In other words, your Java bias has warped your perceptions to such an extent that you would ignore the benefits of Ruby on Rails because you can't get auto-completion in your IDE. :)

19. Sep 2007, 03:48 CET | Link

I'm sort of preaching to the choir here, but perhaps you can use this next point when defending Hibernate/JPA. If you really hate getters and setters, you can always write the entity classes in Groovy. Granted, you are going to take a performance hit, but if you are counting key strokes, the argument works.

Personally, I love using Groovy beans for rapid prototyping when I am trying to work through an association. To each his own.

 
19. Sep 2007, 04:23 CET | Link

Paul, my criticism was not directed at Ruby in general, only at that particular feature of ActiveRecord, which, IMO, is a Bad Thing. Of course, there may well be all kinds of other good things in Rails that make up for this flaw. I'm not willing to venture an opinion on that question here ;-)

 
19. Sep 2007, 04:24 CET | Link

Dan, yes, Groovy is a nice alternative.

 
19. Sep 2007, 04:26 CET | Link

By the way, Dan, if you press ctrl-o, or click the green button, you will get a preview box that shows how the comment will display. For example, we hijacked the / character to do /italics/. If you want a real forward slash, you need to escape it like this

 
19. Sep 2007, 04:34 CET | Link
Patrick Peak

I'm of two minds on this subject. We have been doing a fair amount of work in Rails lately, but I'm also a huge fan of Hibernate, so I like to think I have a balanced perspective (hopefully).

Really, what we are doing here is debating the value of explicitness. What is the direct cost and opportunity cost of being explicit with our attributes?

I do like the explicitness of being able to look at the code, and see what values models support. However, I'm pretty much sold on the Ruby level concept of attribute accessors, which reduce the visual clutter (reducing the direct cost of explicitness). I haven't play around with Groovy much, but I'm pretty sure that seems be what they are doing.

In ruby, you could be explicit (yet more concise than java) like so:

class Company

attr-accessor :name, :ticker-symbol, :persons

end

I would absolutely love to write something like that in java. Each field flagged with an attr-accessor essentially automatically would get a getter and setter generated for me. I know what the naming convention is, why should I have to have my IDEA passively generate it.

Rails' Argument

I suppose the cost of being explicit is it results in duplication. In any ORM solution, you might have to specify an attribute in several places, and be 'right' in each of them.

  1. Specify in code (as an attribute)
  2. Specify in database (as a column)
  3. Specify in the migration scripts (to add or rename the column)

In rails, you still have to do 2 and 3. So really the cost of explicitness is

 
19. Sep 2007, 05:04 CET | Link
Dennis Doubleday | ddoubleday(AT)vocollect.com

Gavin, I think it is going too far to say there is no longer any good reason for people to define mappings in XML.

We still use XML mapping because the software we create is customizable by third party partners. We don't want them to modify our Java classes, but we do want them to be able to change table names, column names, add and/or remove property mappings, etc. The separate mapping file fits this requirement perfectly.

 
19. Sep 2007, 05:20 CET | Link
Gavin King

Patrick, I would love it if Java had a nicer abstraction for attributes (along the lines of VB properties or whatever), but it doesn't. I don't think it's the responsibility of the ORM solution to crudely paper over this language deficiency that has basically nothing to do with persistence.

As was already pointed out, you can avoid the deficiencies of Java by using some other language, for example Groovy :-)

Oh, the wiki syntax is described here, but yes, we definitely need a Seam Text Cheat Sheet linked from the comment box and wiki page editor.

 
19. Sep 2007, 05:24 CET | Link

Dennis, point taken, but this facility is an /advantage/ of Hibernate compared to Active[Record|Objects], so it hardly undermines my contention :-)

Besides, with JPA you can do a default mapping using annotations, and just override those mappings that need explicit customization using XML.

 
19. Sep 2007, 05:39 CET | Link

I don't know Daniel Spiewak and I hadn't heard of ActiveObjects until this article, so I'm not defending him or his project at all. It does appear to me that his criticism of Hibernate is unfounded.

That said, I want to address the question of how attributes are apparent in Rails' ActiveRecord models. I think you'll find that 90% of Rails developers use a Rails plugin called annotatemodels that adds a comment block to the top of the model file with table schema information. It looks something like this (just grabbing a random model from one of my projects):

http:pastie.caboo.se/98456

 
19. Sep 2007, 05:53 CET | Link

Obie, surely it would be better to have real attributes than a /tool-generated comment block/ (!) that documents the hidden attributes?

I mean, isn't the very existence of this annotatemodels workaround pointing to the fact that this is a misfeature of ActiveRecord?

I'm just saying...

By the way, the wiki wants a special syntax for links, I know you tried to link to http://pastie.caboo.se/98456.

19. Sep 2007, 06:35 CET | Link

http://www.javalobby.org/forums/thread.jspa?messageID

 
19. Sep 2007, 06:36 CET | Link

Ah, your comment system eats urls. Just look on Javalobby, the full body of my response is there.

 
19. Sep 2007, 07:24 CET | Link

To those who had trouble with the wikitext language, here is the new help page: ?BROKEN LINK?

HTH

 
19. Sep 2007, 22:06 CET | Link
Patrick Peak

Gavin, Thanks a ton for providing the markup syntax.

I agree, Java's syntax for attributes is really not Hibernate's or any other ORM's responsibility to solve. The java bean syntax for properties isn't ideal, but it works fine. And I think ORM's development staff have better things to do with their time.

History of JavaBeans

In thinking on this, I was wondering why the JavaBean naming conventions (getXYZ and setXYZ) became so wide spread though within Java land as the standard convention for accessing properties. Obviously this isn't specific to Hibernate. The only thing I can figure is that back before annotations came around, the Swing UI guys needs a naming convention on thier methods to 'interrogate' objects to find their properties, and we have all just been following that train ever since.

For example, why wouldn't we just write this:

public class Company {
   private String name;
   public void name(String name){ this.name = name; }
   public String name() { return this.name; }
}

Same accessors, just no bothering with the get or set prefixes. Method overloading solves just fine what otherwise requires different method names. I doubt the following code would confuse anyone.

Company c = new Company();
c.name("JBoss");
String n = c.name();
 
20. Sep 2007, 00:16 CET | Link
I mean, isn't the very existence of this annotatemodels workaround pointing to the fact that this is a misfeature of ActiveRecord?

No. The fact that column attributes are undeclared on the model class is /not/ a misfeature. It is very much a purposeful design choice in the spirit of DRY and is one of the reasons that we (Rails) can do DB migrations in such an elegant and effective manner.

Therefore, the annotate_models plugin should not be characterized as a /workaround/. It is just a convenience. The same information is always available in the auto-generated db/schema.rb file of every Rails project.

You know, I've been doing fulltime Rails development for over two years now and this is simply not a problem. It's the sort of thing you don't really understand until you work with it. In other words, it's a religious belief and I don't expect to make any converts in this forum.

By the way, myself and others set annotate_models as a post-dependency of our rake db:migrate task, so that it is always run whenever the schema changes -- it's really the best of both worlds, not the worst.

20. Sep 2007, 04:54 CET | Link
gbc@gmx.de

Hi,

I just wanted to say that I'm lucky guy with a new Seam EJB3 JBoss 4.2 project to start from scratch. I'm doing J2EE and JEE5 for some yaers now and I never needed to define more than persistence.xml. We have a second project without Seam that works productive with default little modified JBoss and normal configuration amount as well my project runs fine and fast by now. There is nothing more clear than to just write up exactly what you want as an @Entity Bean and let JBoss create the table. Never need to mess up with anything other than persitence.xml. I tried .Net and Typo3, but I'm really happy now being back to EJB3 and good old POJOs and the fantastic new possibilites for a tailored flexible framwork beyond simple examples (and IDE support) for Annotations, Generics, Conversations, Interceptors, Messagine, ... This simply rocks! And if you need specific behavior you may always override by XML (configuration by exception)

So I'm very happy with my setup and may extend it with groovy in a while...

Greetz GHad

 
20. Sep 2007, 04:55 CET | Link
The fact that column attributes are undeclared on the model class is not a misfeature. It is very much a purposeful design choice in the spirit of DRY and is one of the reasons that we (Rails) can do DB migrations in such an elegant and effective manner.

Obie, are you serious, dude?

Sure, so your ActiveRecord class does not explicitly name it's attributes, but /every single class/ that uses the ActiveRecord is /completely/ coupled to the attributes. Worse, in Ruby you have no way to easily rename an attribute in all client code.

In the Java/Hibernate world, renaming an attribute in the whole codebase is as simple as a rename field refactoring. OTOH, if only the column name changes, it is as simple as adding a single @Column annotation. This is a /much easier/ migration.

 
20. Sep 2007, 04:57 CET | Link

/In thinking on this, I was wondering why the JavaBean naming conventions (getXYZ and setXYZ) became so wide spread though within Java land as the standard convention for accessing properties./

I assume that this was a decision made by the JavaBeans EG. I'm not aware that it existed prior to that spec...

 
20. Sep 2007, 04:58 CET | Link
I just wanted to say that I'm lucky guy with a new Seam EJB3 JBoss 4.2 project to start from scratch.

Cheers, man, nice to hear that you are having success :-)

 
20. Sep 2007, 12:43 CET | Link

Gavin, yes I'm serious, dude.

Sure, so your ActiveRecord class does not explicitly name it's attributes, but every single class that uses the ActiveRecord is completely coupled to the attributes. Worse, in Ruby you have no way to easily rename an attribute in all client code.

It's just not a problem in Rails. (Not that I expect you to believe me.)

Out of curiousity, I did some grepping through my Rails projects directory. It contains many of the projects I've ever done in Rails, plus a few others such as Mephisto. By rough count, I have over 700 AR migration files. It's pretty easy to figure out how many times I've needed to rename a column within those migration scripts.

$ grep -R 'rename_column' ./*/db/migrate/* | wc
114     599   13294

That's 57 times (have to cut the number in half, since the command is present in both up and down migration blocks). Of those, a significant number (15) were in a single migration where we went from userid to personid on my current project.

Of course this is all anectdotal and doesn't prove anything. I do want to point out however, that you and others seem to love to judge and criticize Rails based on your needs and realities of the Java world. Don't be surprised when that criticism doesn't make sense to us in the Ruby world.

For instance, you mention /completely coupled/ code... in Ruby? That's really funny. It's just a whole different world man... and don't give me that whole I did Smalltalk jive. It's not the same.

Like the fact that we don't have a rename refactoring in an IDE? Hehehe. Cool. Keep your stinkin bloated IDEs. I love it that we don't need IDEs. You want to rename something in Rails -- just do it. Then run your test suite. Shit breaks. you fix it. Run the test suite again -- done. Of course, that assumes that you have complete test coverage. Most good Rails teams do.

Java projects that have anywhere near 100% or even sufficient test coverage? In my experience they are few and far between (and I spent years on /good/ Java teams. Why? 1) because you have a compiler to provide some measure of assurance and 2) you have about 5 to 10 times or more LOC to maintain.

I could go on and on, but I'll save it for my blog.

 
20. Sep 2007, 15:35 CET | Link

Gavin, the original article you addressed were FUD, you are right. On the Rails side on the other hand, I unfortunately have to tell you, that you are not. You should try Craig McClanahan approach. For starters he is the Struts creator, co-specifier of JSF and did work on the old Catalina/Tomcat. So, a Java evangelists. Guess what, he just did a positive Rails keynote at RailsConf EU. Sun is following the same approach as Tor Norbye has made a excellent job integrating Ruby/Rails in NetBeans. And let's not forget the efforts of Charles Nutter, Thomas Enebo and Ola Bini in JRuby.

Rails is nothing for everything, period. We never disputed that. But, so isn't Java. No Silver Bullet. I lost account of how many times I used that. Hibernate3 is great, Hibernate2 sucked big time - I know, I used it for a long time on too many projects. Problem was: no better alternative available. iBatis? Forget it. And the XML was not the worst part. In a web framework, I really really couldn't stand the way the Session class works. Well, all in the past now, fortunately. As Martin Fowler states: object orientation has evolved to language oriented programming. The Age of DSLs. I forgot how many times I had to refer to the Hibernate Documentation. I was nothing without this documentation. Too many details - and my domain model did crazy stuff, I assure you. With Rails and ActiveRecord I know everything by heart, because its DSL do make a difference. I know the complete Rails framework by heart whereas with Hibernate

 
20. Sep 2007, 16:29 CET | Link

Wow, typos in my last comment, sorry. I meant 'Rails is not for everything'. And in the bottom, 'I cannot think of a similar way to do it in Java'. Finally, I forgot to mention that Rails doesn't need an IDE whatsover. I admire Tor Norbye for NetBeans supporting Ruby. In Java, using an IDE actually does a quantum leap jump in productivity. In Rails, because of the DSLs, the terseness of Ruby you know what to do in a glance. This is not being 'macho' of something: TextMate, some abbreviations, maybe Autotest to make it fancy to do tests and that's all, folks!

 
22. Sep 2007, 08:56 CET | Link
Sean
Sure, so your ActiveRecord class does not explicitly name it's attributes, but every single class that uses the ActiveRecord is completely coupled to the attributes. Worse, in Ruby you have no way to easily rename an attribute in all client code.

Although I agree that ActiveRecord (and Rails in general) has problems, it's even easier than Obie said. You can do anything with the model class you want, so you don't even have to rename the attribute in your code. Instead you could add this to the model class:

def oldcolumn() self

22. Sep 2007, 08:59 CET | Link
Sean

That was my first post on this site. I didn't realize that it would completely reformat the lines of code I posted (and yank symbols like equals).

 
23. Sep 2007, 04:19 CET | Link
topce

Excellent one is comment on Hibernate wich he does not know gavin comment on active record wich he does not know

 
23. Sep 2007, 05:15 CET | Link
You can do anything with the model class you want, so you don't even have to rename the attribute in your code. Instead you could add this to the model class:
def oldcolumn() self; end def oldcolumn(v) self v; end
An even cleaner solution would be: alias oldcolumn newcolumn alias oldcolumn newcolumn The second solution requires the newcolumn accessor methods to exist first, and Rails doesn't always create them until code tries to use them. (I'm not sure if alias counts as the first use.) Either way, the first suggestion will work. Another option would be to override the method missing handler, get it to find the offending lines of code (the ones still using oldcolumn), and make it go change your code for you (both in memory and on disk). This way the code would repair itself while you tested it. ;-)

LOL, and these approaches are supposed to be /better/ than rename field in a Java IDE?

You guys are grabbing at straws here.

 
23. Sep 2007, 05:18 CET | Link
gavin comment on active record wich he does not know

Really? Actually I /have/ taken the time to sufficiently educate myself on ActiveRecord. Do you see any statement I've made about ActiveRecord that is objectively incorrect?

 
23. Sep 2007, 07:13 CET | Link
Paul Beckford

I've been looking at LINQ recently and treating relational database tables as well... data is more honest IMO then trying to pretend that the data in your database is in fact a collection of objects. The simple truth is that most of the time your database record can as easily be represented as an hashmap of name value pairs, then as an object.

Of course with an hashmap you do loose representation independence out of the box, but as Obie points out the number of times that this really matters is extremely small. On the other hand the number of times you end up with anemic objects in your ORM solution that consist solely of getters and setter is extremely high in my experience. And all that boiler plate setter and getters... for what exactly?

I think this the real difference here is that Agile/Rails folk are willing to suck it and see what really works in practice, whilst BDUF/Java people tend to live in fear of what could happen and want to rely on their compiler/IDE instead.

A lot of what we do in Java is verbose over Engineering and from what i've seen of LINQ it is yet another testament to the point of view that often less is more, and that the choice of language is more important then the choice of framework.

Paul.

 
24. Sep 2007, 06:41 CET | Link
topce
At this point, most developers are thinking um, ok, so how the hell am I supposed to know what attributes a Company has by looking at my code? And how can my IDE auto-complete them? Of course, the Rails folks have a quick answer to this question Oh, just fire up your database client and look in the database!. Then, assuming that you know ActiveRecord's automagic capitalization and pluralization rules perfectly, you will be able to guess the names of the attributes of your own Company class, and type them in manually.

read artivle http://www.ibm.com/developerworks/java/library/j-cb03076/index.html

class Person

 
01. Oct 2007, 10:10 CET | Link
The simple truth is that most of the time your database record can as easily be represented as an hashmap of name value pairs, then as an object.

Whoah there! /Most/ of the time? C'mon, the simple truth is that most of the time it is definitely not OK to represent the central, most basic model of your business as a hashmap. It might work fine in the kind of applications that people use PHP/Ruby for. It's not OK for applications that actually matter.

Of course with an hashmap you do loose representation independence out of the box

What you lose is object orientation.

On the other hand the number of times you end up with anemic objects in your ORM solution that consist solely of getters and setter is extremely high in my experience.

That is not my experience. Again, it is probably true for the kind of applicatons that people use PHP/Ruby for (ie. applications with only trivial business logic).

And all that boiler plate setter and getters... for what exactly?

For being able to refactor your code with tools, as has been explained many times.

I think this the real difference here is that Agile/Rails folk are willing to suck it and see what really works in practice, whilst BDUF/Java people tend to live in fear of what could happen and want to rely on their compilerIDE instead.

Wow, Java=BDUF, Rails=Agile? Since when? I've never done a BDUF in my life. What has the programming language got to do with the process used?

 
01. Oct 2007, 10:18 CET | Link
So convention over configuration doesn't unnecessarily restrict you, it just rewards you for consistent naming.

Sometimes restrictions are good. I don't need too many restrictions when I'm the only guy working on the codebase.

I /do/ need them when I'm sharing the code with 20 other developers of a wide range of skill and experience.

Everyone wants to use Rails for the first two hours of coding. But how many people will want to maintain a legacy Rails codebase in 5 years from now?

 
01. Oct 2007, 13:06 CET | Link
Cho

Gavin,

You must have been very fortunate to consistently find Java codebases that are easily maintainable after 5 years, especially if there were 20 other developers work on it. But let me tell you in reality that is often not the case.

A maintainable project is a by product of excellent software engineers not of the language nor framework. You can find maintainable and unmaintainable code bases written in any language using any framework. Although, it appears the latter is by far more common.

I understand your coming from a post that made pot shots at hibernate but you shouldn't stoop to the same level. Especially considering that your attributing several key features to an IDE. There is nothing to stop people from implementing the same features into their choice IDE for their choice language and framework.

Cho

 
01. Oct 2007, 19:55 CET | Link
random8r | j(AT)leviston.net

Um, actually if we want to know what attributes a class has, we look in the db file.

OR we could use a certain plugin which automatically creates puts comments indicating the attributes into the class for us. ;-)

It's not as much of a problem as you'd expect it to be. ;-)

 
03. Oct 2007, 01:36 CET | Link
You must have been very fortunate to consistently find Java codebases that are easily maintainable after 5 years, especially if there were 20 other developers work on it. But let me tell you in reality that is often not the case.

Correct, it is often not the case /even in Java/. The situation gets /even worse/ in more dynamic languages.

(Yes, I have actually maintained legacy codebases in dynamic languages. I coded Smalltalk before I coded Java.)

 
03. Oct 2007, 01:36 CET | Link
Um, actually if we want to know what attributes a class has, we look in the db file. OR we could use a certain plugin which automatically creates puts comments indicating the attributes into the class for us. ;-)

Wow, and both these options totally suck ass compared to /just having a proper attribute declaration/, don't you think?

I thought the point was that this ActiveRecord stuff was supposed to be /better/ than Java?

Not that it required crazy workarounds like automagic generation of comments that list the basic attributes of my business domain model!

 
05. Oct 2007, 12:57 CET | Link

Before I start beating the dead horse, let me first say that Hibernate is the bomb and one of the most useful technologies in the world - so Gavin's got that going for him, which is nice.

But I guess I don't understand the vitriol of either side in this debate - the differences being discussed are due to the design patterns being used, not the inherent crappiness of either technology. For example, it doesn't really make sense to say (as a negative) that you're delegating the domain model to the database in Active Record, since the design pattern dictates that model objects and the database tables that represent them are conceptually one and the same. In that pattern, it could be considered redundant to have attributes declared in both the model object and the database.

Each pattern has strengths and weaknesses. As a matter of opinion, I find Active Record is easier to use when there is no need for a layer of abstraction between the business model and the database. However, it often happens that the extra layer of abstraction is useful for a variety of tasks, including but not limited to dealing with legacy schemas.

I think it is indisputable that Hibernate 3 outshines Active Record in both performance and sheer breadth and depth of functionality. Active Record is just a piece of the Rails pie that works well in concert with the rest of the framework. I think it is that harmony which is the special sauce of Ruby on Rails - not its persistence framework per se.

P.S. - What I think would be useful in Rails is a hybrid approach where model objects are mapped to the database via a layer of abstraction, but the model objects retain the ability to persist, find, and validate themselves a la Active Record. Anyone want to get on that for me? Gavin?

 
08. Jan 2008, 22:33 CET | Link
matt m

Gavin said:

crazy workarounds like automagic generation of comments that list the basic attributes of my business domain model!

Ummm...it's not a workaround. It's the way things work. And it's a lot less code than having the attributes called out. Although, you could easily use Active Record in exactly the way you are suggesting, by wrapping the attributes with functions. It would just be redundant in the cases where your attribute matches your column.

It's definitely miles better than Java. I've been living in both worlds for two years now, and it is painful to repeat myself across objects and data in cases where it is not necessary- which is most of the time.

I've also found ActiveRecord migrations to be the absolute killer feature for agile database development. I hope Hibernate gets those soon!