- Re: deriving the model from the database:
getting attributes from the database is straightforward. Creating
validations & associations from constraints is not, because
constraints often have semantic meaning. It would be difficult to
define, and it would be brittle. As far as things like not null, etc.
I don’t see what the advantage would be to have rails creating magic
validation. You would still have to write code to handle the
failures. That would involve defining a method. The only difference
from the current situation would be the name of the method – it
would be like, failed_validation_of_xxx instead of validates_xxxx.
if the association were magic, not in the entity code, it would make
the app extremely difficult to read.
If all you want is the associations autogenerated into the entity
code, you could roll that into the generator script. For a very large
model with straightforward semantics done all at once, it might save
you a little bit of time. For incremental development, it would
probably cost you time. The act of manually typing in the
associations helps you check your mental model of your model and make
sure you’ve got it right.
- Re: deriving the database from the model.
Although the sweet spot for Rails development is from-scratch web
apps with db designed for the web app, deriving the db from the model
would restrict it to that arena, which would not be a good thing. And
there’s no productivity advantage: somewhere I have to define a set
of tables & attributes, there’s no productivity advantage to it being
in the ruby code as opposed to sql. The advantage of having it in sql
is that I can use pre-existing databases, I can tailor the
definitions to my specific database, etc. If the db was derived from
the model, I would frequently end up in the situation of having to
coerce an abstraction layer to carry a semantic meaning that I need
for a particular situation that the framework developers didn’t (and
neither could have nor should have) anticipate(d).
All things considered, the way it is is probably the best way that it
should be. It is a reflection of the fact that the framework
developers had a lot of experience developing web apps, and thought
about it deeply & pragmatically. It has compromises. They are the
right – or at least very good – compromises for the target.