[storm] some questions about Storm (from the perspective of Grok)

[James Henstridge]

On 15/03/2008, Sean Allen <sean at ardishealth.com> wrote:
>  > I do think it would be useful to have some tool that helps people
>  > manage a database schema as a series of patches though.  I've been
>  > told that Ruby on Rails does this quite well.

For those wondering what I was talking about here, the API reference
for this part of Rails is here:

    http://api.rubyonrails.org/classes/ActiveRecord/Migration.html


> Rails works from a different perspective. It introspects on the database
>  and auto creates various model properties from that. The migrations
>  are used to handle moving data to a new schema within the context.

The point I was trying to get across is that it treats the database
schema as something that changes over time rather than something you
can generate from the current state of the application code.  I am not
so interested in the exact details of how it is implemented in Rails.

We implemented a similar (much simpler) system for Launchpad.  The
main differences were that we didn't support rolling back migrations
and all migrations were done as SQL scripts.

>  There is no reason why a generate schema from class feature couldnt
>  introspect the database, see what differences exist with current
>  model definition and alter the table keeping the data intact.

Having worked on a large project that has gone through many migrations
over the years, I can say that this was almost never the case.

There are few cases where you just remove a column without migrating
its contents to somewhere else.  Similarly, it isn't uncommon to want
to fill in a newly added column from some existing data.


>  Its obviously more complicated ( and in some cases impossible )
>  but given that in many situations ( perhaps most ) it could be handled,
>  I dont see why you wouldnt want it.

It makes sense to provide an easy way of doing these simple schema
changes, but I definitely wouldn't want to see them done automatically
(especially when it might destroy data).


>  If I'm adding new tables or doing anything that a simple alter table
>  sql can do, then why wouldnt i want the orm to handle it automatically
>  and I can deal with edge cases?

How does the ORM know the difference between creating an unpopulated
table, and migrating some existing data to a newly created table?


>  If I have to define the schema in sql then really, I shouldnt have
>  to list out everything again in my class. Defining the same
>  information in
>  two places ( create table, migrations ) and in the code just strikes me
>  as wrong.

There are many migrations that you can't infer from the current state
of the database and the current application code, such as table or
column renames.  And I don't think it would be an improvement to add
such annotations to the application code.

Furthermore, I don't want information about triggers, indexes, stored
procedures, etc clogging up my application code.


>  Ideally, I want an orm that either acts like ActiveRecord and
>  introspects
>  as much info out of the database as possible leaving my models
>  as spare as possible or one more like DataMapper which handles
>  the schema creation ( although not migrations yet ) as much as possible.


James.