Luke Skibinski Holt wrote:
Absolutely - I had never thought of anything like that before. It's pretty daunting compared to the easy way (automating the dumping/reloading and manual editing of sql files). I think the implementation of such a beast would be very difficult though - there are too many gotchas that have broad impact on the rest of the db. It's easy enough to prune away at a model but the real difficulties come when you want to add new fields, especially required fields. I was just hoping for some django magic to do it all for me ;)
I've done some thinking about this with past (php) frameworks, and it does strike me as odd that after all the work we put into automating version control of our source code and our desktop installers... but yet we don't have much of use for data schemas beyond hand writing SQL, which can often be imprecise (maybe you forgot a few changes) and in the case of using a decent ORM is not very DRY.
Obviously the full implicit system is out of bounds for some of the reasons the parent mentions. We worry about our data if a fully implicit system is doing the work. On the other hand, the fully explicit techniques mentioned further up the message family aren't DRY and can get annoying/irritating.
The key to any endeavor into such a field would be to step gradually in the direction of a true modern version control. Here's some of the steps that I see:
* How about an ``sqldiff`` command to sit beside the others like ``sqlclear`` and ``sqlreset``? You have the model, you have the current db schema... show me what the differences are and I'll have a quicker time in writing SQL to fix that. Even cooler: I'm using version control, if I give the tool two model files, could you give me the difference between the two in terms of the SQL? Neither of those should be that tough, should they? But both should be that much more useful in moving to a good model versioning system.
* How about a useful Schema Introspection API? Things like ``MyModel.objects.db.has_field('my_field_name')``... Not only would this be useful for migration scripts (``if not MyModel.objects.db.has_field('my_field_name'): # Add Field SQL Script``), and fun things like automatic migration on the first save(), but could be useful for creating "polymorphic" models that adapt to the current db schema (for instance, I was thinking about very modular systems that have "installable" options, and the current easiest way to do this would be to have seperate "glue apps" with relational models, but it would be neat to have models react to whether or not other models, or certain fields of their own model, are "installed" in the database).
* Then, how about a useful "Schema API" to add the fields and update the fields based on the Model information? Once you have ``MyModel.objects.db.has_field('my_field_name')``, then you can think about things like ``add_field()`` or ``update_field()``. With those even cooler migration scripts could be built, and it could make it real quick to update a database from the Python console.
Those are my thoughts at the moment, feel free to see if they are useful or necessary. ("Do the simplest thing, but no simpler", right?)
-- --Max Battcher-- http://www.worldmaker.net/
