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. -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
