This thread is of interest to me as well, although the problem I'm
facing is somewhat different. Just to expand the space a little, here's
my situation:
- A legacy database schema with hundreds of tables and procedures.
- An application that accesses the database, with occasional updates
delivered to customers (not all of them will upgrade at once) -- each
update needs to update the database as well as part of the installation
(with live data existing in the database, of course).
- Customers may add some of their own tables and procs, and have custom
versions of some standard procs. (Maintaining those is the customer's
problem, although we do help.)
To bring some sanity to this, I've created a folder hierarchy of scripts
and some programs to apply them to create or update a DB (I call it the
Standard Database). This hierarchy is under version control. Still,
though, it's too unwieldy to distribute and manage, and doesn't solve
all the problems. Currently, we just have a folder of scripts
associated with each update and run them against the customer's DB.
This leaves us with the duplicate script problem, of course; sigh.
I'd like to turn the Standard Database into an application that would do
the kinds of things being discussed here, in particular upgrading a DB
as appropriate, while respecting both the live data and local
modifications. Part of this would be something like a "DB diff" that
could let the user know what needs to be updated.
Just a brain dump at this point,
--
Don Dwiggins
Advanced Publishing Technology
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected].
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.
