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.

.class Author /regex/
. end
.end
.
.# [...]
.
.class Post 3..100
. end
.
. attribute :summary, :text
. attribute :content, :text
.end

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

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

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.

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”

http://www.djangoproject.com/documentation/model_api/