Rails could be DRYer
I'm playing with Ruby on Rails these days and I've been thinking about how Rails isn't entirely DRY. (i.e., doesn't implement the Don't Repeat Yourself philosophy fully.) The area where it falls short of DRY is in the duplication between defining the database schema (either manually, or through the use of migrations) and defining the Model.
The Rails could be DRYer article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
In Rails you can define constraints and validations in the Model. You repeat the Model definition when you create migrations to create your database structure (or if you create you create your schema manually, when you do that.) You repeat the constraints (e.g., foreign keys) in the database also. For Rails to be completely DRY, it should generate the schema and update the database automatically based on the current state of your Model classes. (Allowing overrides that go low-level, where necessary, of course for specific optimizations or advanced SQL.)
Googling around, I came across this discussion of a suggestion for ActiveSchema where people are discussing the same thing.
The Rails could be DRYer article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Thom Shannon
I’m having the same problems trying to find a decent ORM for .net, you basically have to design your object model in the db and code gen it into your DAO layer if you want a quick and easy way. But then you ROR kids aren’t interested in that stuff
October 11th, 2006 at 12:13 amNick
The Castle Project, i.e. MonoRail or “.NET on rails”, has an implementation of ActiveRecord similar to RoR, except the underlying technology is provided by NHibernate which does allow you to create your database schema automatically from your attribute-based object markup. It’s an enormous timesaver during early-stage development when your data structures are constantly being refactored!
October 11th, 2006 at 8:18 amMartin
You might like to have a play with Django, I dont like fiddling with databases it takes me away from the warm cosy comfort of coding.
October 11th, 2006 at 8:19 amhttp://www.djangoproject.com/documentation/model_api/
Dan Glegg
It’s not as unDRY as you’d think. Rails is automatically coercing data between your field types and ruby native objects, which is defined by your database schema. You don’t have to re-code any attributes except those which you want to place behaviour (such as validations, or relationships) on - which MySQL doesn’t support anyway.
So it might seem like a pain, but in reality you’re getting an awful lot for free.
*wanders off, whistling “always look on the bright side”
October 11th, 2006 at 10:09 amaral
Hi Dan,
The duplication is in having to manually define the schema when it can be inferred from the Model. RoR definitely gives you a whole lot for free — this seems to be the main bit where I’ve noticed any duplication.
October 11th, 2006 at 10:33 amcies
i totally agree… and i have investigated in this issue. (you can search for my name on rails lists)
what i suggest is a sort of ‘ManagedRecord’:
- write your db schema in ruby code; inside your model
- let the ‘framework’ generate migrations for you (when it encounters your models do not match with the db anymore — this should only work in development modes)
- have the attributes and the validations etc. all at one place (the model ruby code)
here a small example:
class Author /regex/
end
end
# [...]
class Post 3..100
end
attribute :summary, :text
attribute :content, :text
end
i did a small investigation and concluded that this could never be implemented inside (or as some sort of extention/plugin/etc to) ActiveRecord, because of technical difficulty and because of the rails not seeing the unDRYness as a problem.
that’s why: ManagedRecord will be needed.
i have no clue if Managed- and ActiveRecord could cooperate, of it it would be possible to maintain compatibillity with AR plugins. my guess: mostly likely not.
ManagedReocrd will put a lot more stress on the implementation of the database interface, it might also enable the developer to use stuff like database-side referential integrity (and other database features) with very little efford.
important: what happends if a ManagedRecord model is no longer matching the db?
- in development: an exception should be raised, and catched by the framework to start the auto generation and execution of a migration (this could be accomplished by a web based interface)
- in production: this should never happen! when the models are updated on a production server the migrations also have to update.
pfff…. long comment, i hope some one reads it.
with questions, or further investigations: please mail me (cies,at;kde:dot.nl).
Cies Breijs
October 11th, 2006 at 12:51 pmcies
THE ABOVE CODE BLOCK GOT MANGLED…
HERE I TRY AGAIN:
.class Author /regex/
October 11th, 2006 at 12:56 pm. end
.end
.
.# [...]
.
.class Post 3..100
. end
.
. attribute :summary, :text
. attribute :content, :text
.end
cies
again the code got mangled…
it is basically the same as i wrote here (see the bottom of the page):
http://wiki.rubyonrails.org/rails/pages/ActiveSchema
i only changed the ActiveRecord super class into ManagedRecord; this because i found that it is mission impossible to implement it into the existing AR.
October 11th, 2006 at 1:18 pmaral
Thanks, Cies. Sorry my blog mangled your code block.
October 11th, 2006 at 5:00 pmgiles
I think the counterargument would reference levels of abstraction. Implementing a system which automatically generated schemas based on the Model could create a solution which was more complicated to implement than the problem it solves.
October 15th, 2006 at 3:36 am