I was reading this article on developerWorks about GORM, the OR framework in Grails. Like everything else in Grails, it is "inspired" by Ruby on Rails. In this case GORM was inspired by ActiveRecord. In GORM here is an association:
class Airline {
static hasMany = [trip:Trip]
String name
String url
String frequentFlyer
String notes
}
Compare this to the same thing in Rails
class Airline < ActiveRecord::Base
has_many :trips
end
Forget the explicit listing of fields for a minute, concentrate on the has-many notation used by both frameworks. In Grails, you have a static field that has a special name. In ActiveRecord you use a meta-API or macro (or whatever you want to call it) to dynamically add methods to each instance of Airline. Grails accomplishes the same thing, but it is much more of a hack. You just happen to have a static field that has a special name.
It just feels like "wow that feature is cool, we can't do it the same way ... but we can hack something together that is pretty close!" Just seems like Groovy comes up short.
4 comments:
[Pedant] In Rails the convention is:
has_many :trips
which reads better, as well.
@baz Yes you are right. I corrected it as such.
On the "hack"issue... I'm no expert in Groovy (or in Ruby for that matter!) but it seems like you should be able to do things more like how ActiveRecord does it. Obviously your object needs to extend a base class, or just call a static method on it directly. You would have to use the naming convention to go from trips => Trip.class essentially.
So maybe it is not a failure on the language, just a choice by the GORM developers that looks like a hack to me (even if it is not.) It still does not bode well for Groovy IMO. If Rails would have been similarly written, it would not have been good for the Ruby language either. The success of Rails has brought a lot of people to Ruby.
Seems fairly shallow to condemn an up and coming framework based on one small aspect of it's OR mapping.
Post a Comment