Aral Balkan

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.

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.

Comments

• 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 ;)

  by Thom Shannon on 2006-10-10 23:13:49

• 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!

  by Nick on 2006-10-11 07:18:33

• 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. :) http://www.djangoproject.com/documentation/model_api/

  by Martin on 2006-10-11 07:19:53

• 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"

  by Dan Glegg on 2006-10-11 09:09:41

• 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.

  by aral on 2006-10-11 09:33:37

• 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

  by cies on 2006-10-11 11:51:46

• THE ABOVE CODE BLOCK GOT MANGLED... HERE I TRY AGAIN: .class Author /regex/ . end .end . .# [...] . .class Post 3..100 . end . . attribute :summary, :text . attribute :content, :text .end

  by cies on 2006-10-11 11:56:20

• 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.

  by cies on 2006-10-11 12:18:41

• Thanks, Cies. Sorry my blog mangled your code block.

  by aral on 2006-10-11 16:00:58

• 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.

  by giles on 2006-10-15 02:36:20