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

[Sean Allen]

On Mar 15, 2008, at 11:29 PM, James Henstridge wrote:
>
>> 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).
>

i doubt anyone would want anything of the sort being done automatically.

>
>> 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?
>

honestly i don't know. there are lots of issues here, it comes down in
the end to my desire to encapsulate everything in one place. be it
in python/ruby/java or sql database or whatever.

things that tweak my 'there has to be a better way' switch:

database introspecting orms that dont handle simple things like
automatically validating that a field i defined as NOT NULL in my
create table has a value on record creation/update ( and many things  
grow from there ).

orms where i have to declare property values in both code AND again in  
sql.


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

i've often thought that perhaps the problem here is a missing tool.

if i could declare what my data store and all its validations etc look  
like
in a tool specific language that can then take that and translate into
the appropriate sql and python ( which all the variations, turn out
sql object and storm or ruby and active record ) code from it
and it provided migrations as well so i maintain one specification,
i would be a happy camper.

would certainly be interesting... write different plugins you can  
specify to
target your particular deployment environment.