On 7/31/07, Derek Anderson <[EMAIL PROTECTED]> wrote: > testing and documentation (plus two minor bug fixes) are checked into > the schema-evolution branch: > > tests/modeltests/schema_evolution/models.py > docs/schema-evolution.txt
Documentation should be about how to use a feature, not how the internals of a feature work. These docs are great for showing what SQL will be generated - but they aren't much help to the end user. They don't answer the questions "how do I start the migration process? What do I need to define to make a migration happen?" Read the original wiki proposal again - how does this documentation help Alice? However, reading between the lines, here are a few quick comments: - The introspection stuff is neat, but I _really_ don't like the aka representations in the model. The models file should always be a clean statement of the current state of the model. Migration is about getting an old database to match the currently required models - if I don't have a legacy database, I don't really want the cruft hanging around in my models. Migration plans or historical models really should be kept out of the core model file, IMHO. - Unless I'm missing something, the aka approach doesn't track exactly which name versions correlate with other versions. Consider; your aka chain for one field could indicate a rename from 'foo' to 'bar' to 'foo' to 'bar'; a second field could indicate renames from 'whiz' to 'foo' to 'whiz', etc. A tuple of historical names doesn't tell me which sets of names were in use concurrently; so if I find a database with a field called 'foo' which requires migration, is 'foo' the first field or the second? - Your patch doesn't seem to address issue of cross-platform SQL. I know of at least one major cross platform problem - quoting the SQLite docs: "SQLite's version of the ALTER TABLE command allows the user to rename or add a new column to an existing table. It is not possible to remove a column from a table." I can't see anything in your code that provides an alternate mechanism for removing columns, or providing a warning if you try to remove a column from an SQLite table. - Your patch doesn't seem to address the issue of sequential evolution - changes that must be applied sequentially (rather than just adding/removing columns to get you from current database state to current model definition). This is particularly relevant when you start looking at doing data conversion as part of the migration process - Speaking of which - how does data migration fit into this model? > > because I suspect the existing test framework will require some > > modifications to enable models to be evolved during a test run. > > yeah, i spent some time trying to figure out how i could load a model, > change it, then run the evolve introspection scripts. but in the end, i > just wrote sql to simulate what the model used to look like. i figured > low-impact==good. (but i'm open to different ideas) I don't see how you can test schema-evolution without reloading models. The tests you have are useful - they demonstrate that the right SQL is generated - but this doesn't help if the SQL can change on a per-backend basis. SQL generation is also the least complex part of the entire process. Your tests don't check that complex part - the introspection is being done correctly. There is no use in generating the correct SQL for a rename if you can't identify what constitutes a rename :-) 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 -~----------~----~----~----~------~----~------~--~---
