lets think my real world. i build a (very) complex tree of objects - the model of the application data and relations within. i express this model in some "language", implicitly or explicitly, then, automaticaly (or almost-), map this model into set of db tables, constraints etc. and this is done opaque, i.e. i do not care what they will look like as long as they function as i have requested.
Now the model changes. So i do re-build the mapping, eventualy easy getting another set of tables constraints etc. So now i will have both old and new models, old and new mappings, and old and new set of db-stuff (SA metadata). and i will have to convert stuff from old to new ((or simulate it where gone missing). i think managing the first two would take more than enough horsepowers, and i'll have nothing left to manage the last one. Can "migrate" do (most of) that for me? i vote yes. (-:) Apart of that at every start of the app it should gather what the current metadata in the database was, and compare it to the one it is going to use _now. And if they dont match... trigger a migrate? svil > Speaking purely as a user, the question of rewrite or no rewrite is > not as important as making sure it is stable and supported in some > way. > > In a perfect world what I would like to see is that it is rewritten > to a point that it doesn't break and that it satisfies Michael to > the point that it could be assimilated into SA proper. It seems > like an important enough SA feature/capability that it makes sense > to put it into the base package so users can rely upon it being > there and so there can be test suites to make sure it keeps working > as SA changes in the future. > > But that is just what I think, what do other users think about the > future of migrate? > > -Allen > > On 6/27/07, Evan Rosson <[EMAIL PROTECTED]> wrote: > > I'm still around; unforunately, I'm afraid I lack the > > time/motivation to put much more into migrate. I've no objections > > to someone else taking over the project, if anyone's interested. > > > > For what it's worth, there's a mostly-finished svn branch that > > removes monkeypatching, no changes to SA required: > > http://erosson.com/migrate/trac/browser/migrate/branches/monkeypa > >tch_removal Haven't moved it to trunk/released it because I never > > got around to fixing constraints. Looks like it may be out of > > date once again too; but if anyone's up for taking over migrate, > > it's a better place to start than trunk. > > > > On 6/27/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > Based on the non-responsiveness on the migrate ML, I think > > > migrate needs someone to take it over at this point. I would > > > favor a rewrite that doesn't rely upon any monkeypatching > > > within SA (which would have prevented the breakage upon version > > > change), and I also had agreed earlier to allow "ALTER TABLE" > > > hooks into SA's dialect to smooth over those particular > > > operations which currently are bolted on by migrate's current > > > approach. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
