On 8/29/07, Graham Carlyle <[EMAIL PROTECTED]> wrote: > > I was hoping something similar would be tenable for the production phase > as well... just dumping the data and then re-loading after recreating > the database, with some possible data munging if the schema has changed > in an incompatible way. For my project the downtime for the > dump/rebuild/load cycle should be short. Also I'm imagining scripts to > modify yaml will be more straightforward & flexible than doing any > manipulation with SQL. > > Does anybody think this is a reasonable solution or am i missing > something?
A few little things :-) 1) If you have a non-trivial amount of data in your production database, the space and time required to deserialize, store and reserialize the contents of the databse could be problematic. 2) The technique you propose doesn't address any changes that may be required to your data. This isn't a problem if you all you do is add a new field that allows null=True, but if you add a non-optional field, the fixture load won't work because the fixture won't contain data for the new field. At the very least, there is a transform step between the dump and the load. Solving this sort of problem is what the SQL ALTER statement, and by extension, the schema-evolution pushes, are all about. These change the database in-situ, rather than going through an intermediate database. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
