On 8/6/07, Derek Anderson <[EMAIL PROTECTED]> wrote: > > who wish to perform different combinations of the two basic subtasks of > schema evolution: > > 1. generation of SQL via magical introspection > 2. storage and auto-application of upgrade SQL > > the first i've detailed before, so i won't cover here. it works the > same way.
Again - IMHO, the 'aka' syntax is a non-starter (for all the reasons I have stated previously). Unless you get a BDFL or majority core-dev pronouncement to the contrary, or you can provide a compelling reason why 'aka' is desirable, it's probably safe to assume that schema-evolution with 'aka'-style syntax as currently proposed won't be merged to trunk. > * full migration graphs should be supported, not just linear steppings ... > * a list of known schema fingerprints > * a dict mapping (from_fprint,to_fprint) pairs to scripts (lists of > sql statements and/or python function calls, to be run in order...think > pre_script/sql/post_script) This is an interesting idea. Some comments/questions: 1) Isn't the list of known schema fingerprints just the list of keys in the migration graph/dictionary? 2) From your code, a schema fingerprint is a hash of the output of SHOW TABLES; this is an interesting approch, but there will be a major problem going cross-platform. If I remove a field from a model, the rough description is platform independent, but the SQL required isn't. As a result, I would need to manage multiple sets of migrations - one for each database I have to support. Wouldn't the model itself be a better source for the fingerprint (or, at least, and abstracted representation that has been derived from the database)? 3) If you are using fingerprints to identify nodes in the graph, how do you handle cyclic states (e.g., v1, I add a field, v2 delete it ,v3 add it again)? As I read your proposal, the fingerprint for v1 and v3 should be the same - which will cause some major problems determining resolution order for applying migrations. 4) If you are using model fingerprints to identify changes, how do you propose to keep parallel changes synchronized? For example, Model 1 goes from v3->v4, but that change relies upon Model 2 going from v6->v7. If the pair of changes share a common label, the label can be used as a point of synchronization; however, the fingerprint (by itself) doesn't provide such a reference point. 5) What is the role of the post-state here? Is it your intention to use the post-state for validation that a migration has been successful? If so, how do I populate the post-state value before I have applied the migration for the first time? Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
