On Friday 27 July 2007 23:18:17 Paul Johnston wrote: > > It's been great to see the recent discussions on this. An area I've > been meaning to do some more work on for a while. I've noticed > there are two main schools of thought on this issue: > > 1) Some people want the database layout to be completely defined in > the database and have the Python side read that automatically. > 2) Others want to have the Python definitions be the master record > and have the database adapt itself to them. > > As it stands, SQLAlchemy already has pretty good support for (1), > with table autoload, the recent ability to pickle metadata objects, > and also with SqlSoup. missing is the metadata.autoload itself, i.e. u can autoload a table only if u know/hope it exists.
> Support for (2) is more limited, with the > migrate project being the main tool available. afaisaw yesterday, it goes some great lengths about bookkeeping of the version-change scripts, but nothing about helping write the scripts themselves - DIY. > Some tools that would be useful are: > > 1) Build python table definitions from a live database (i.e. > AutoCode) > 2) Tell you where a MetaData differs from a live database > 3) Automatically build migrate scripts for simple database changes > (e.g. adding a column) > Now, I think we're hitting the limits of having such tools in the > UsageRecipes on the Wiki. Mike - is this something you'd be > prepared to have in SQLAlchemy, perhaps in a "scripts" > subdirectory? Otherwise, I wonder if we should pick up the migrate > project again and add these kinds of abilities. i also have couple of SA-related scripts i did for dbcook. e.g. the sa_generator. apart of the autoload/metadatadiff. > One other thing while I remember, how about adding a function > all_table_names (to return list of table names in a live database) > to each database's dialect? This would get rid of > database-dependent code in tools like AutoCode. not only tables - indexes, ... schemas, functions, triggers, whatever lives at that level, for that particular dialect. imo many things can go in SA, be it dialects or not. The way there is able(autoload=1), there should be Metadata( autoload=1); the way there is reflect_table() in dialects, there should be reflect_metadata() etc. the metadata traverser/comparator is also candidate for a metadata.compare() method, with the support of lots of lower level objects - tables/columns/constraints/... e.g. .compare() method on all shema items. For now all can stay separate, until its more working. do check my metadatadiff at dbcook.sf.net's trunk. What i achieved there should be enough for adding/removing/ value-modifying of things. renames are tricky, moves are even trickier, probably forget them. Splitting X into joined-inheritance X1 and X2, and combining back might be interesting... Anyway i'll be outside of internet next 2 weeks, so u can pick it up and go ahead. i could not decide on some things, e.g. how deep to stop being picky and just compare str(x) - or x.__dict__. Too lazy to write .compare() on _everything_. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
