During the development phase you can alter your
classes and Og automatically adapts the schema for you. In this phase
you generally don't have any real data to care about.
That sure depends on the application and your willingness to eat your
own dog food. Basecamp, Ta-da List, and Backpack were all managing
our real data shortly after the first SVN check-in. Hence, the window
of not caring about loss of data was essentially nil.
From the point where you have data that matters, the object-to-SQL
(OTS) approach is merely yet another step required to evolving your
domain model.
In Rails, adding the field address to the model Person is one step
during development:
1) Adding the field in the db (how fast that is in practice can be
seen nicely in the initial Rails window that tabs back and forth
between editor and DB GUI in seconds).
The same change in an OTS system is a repeating two-step approach
where you first inform the database of the change, then say the same
to the domain model.
- uses standard Ruby objects and not beutified hashes.
Heh. Who needs to beautify a hash? She's looking mighty good to me.
And if she needs more sassy, I'm sure _why and his foxes can do a
much better job than a framework abbreviated as AR(GH).
Seriously now.
- you can switch the backend RDBMS by changing one line of code.
That is indeed an alluring prospect. To be able to generate SQL for
multiple flavors from a single definition. Some applications truly
need that. Which is why Active Record is getting an optional
definition style just for this purpose. I could definitely see
Instiki on Active Record use this to good effect.
It's however not something that matters for a large class of
applications, like the ASP-based ones from 37signals. So burdening
all with repetition needed by few didn't seem like a trade-off that
made sense for Active Record. (Somewhat related to that is the Jeremy
Zadwodny's argument that "Database Abstraction Layers Must Die!" --
http://jeremy.zawodny.com/blog/archives/002194.html -- especially in
the context of using find_by_sql, execute, and the option that SQL is
not evil).
Now what's much more interesting than OTS or STO is how to deal with
an evolving database scheme where you can't throw out the data on
every change. Martin Fowler had a good discussion on that in his
Evolutionary Database Design[1] article.
Active Record is tackling this problem through a new system called
Migrations, which basically turns the database -- data and schema --
into a revision controlled system that can be evolved just as easily
as code (integrated into the Rails workflow as well).
When you're using migrations, the complete schema is a lot less
interesting than the diffs. With migrations, it's easy to allow
multiple developers to be at separate stages on the evolving
database, like Fowler's article describes. At the same time, it's the
system you can use in your deployment chain.
Which is of course exactly what we're doing for Backpack now. Jamis,
the designers, and I each have our own database instances and are
happily keeping in sync through Migrations. And when we decide to do
"rake deploy", the live version keeps up.
[1]
http://www.martinfowler.com/articles/evodb.html
) Adding the 1 line for Og takes 0.5 minute. Changing all your code