FYI - the schema evolution code submitted from the SoC project doesn't work, so keeping it up to date is a moot point. There have been several posts from people trying to use it where the SoC version of the schema evolution code just halts.
The implementation in my patch is basically a complete rewrite. The only things I've kept are the 'aka' attribute definitions in the Field and the Model.Meta classes. vic On 12/15/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > > > There was discussion about the general problem of schema evolution > > before the SOC project was started. The discussion was started by > > Jacob, and other committers (Luke and Malcolm) weighed in at the time, > > along with many other interested onlookers. The resulting design is on > > the wiki. > > That's good to hear. > > > Assuming that the implementation matches the proposal, I would say > > there is a realistic chance of it getting accepted into core. However, > > this would require that the implementation is up to date, and bug free > > (including tests to validate this status that are integrated into the > > Django system tests). > The tests I've added to the schema evolution code are fully automated, but they aren't currently integrated into the main Django test suite. The main reason for this is that the schema evolution code relies on a Postgresql backend. You can't run the tests against MySQL or SQLite. MySQL doesn't work because I haven't looked at it yet, and SQLite is probably going to be impossible to implement since sqlite doesn't implement a proper ALTER TABLE statement. > I see. It sounds like it may be a bit of moving target, due to changes > in core. Maybe a good goal would be to get the implementation up to > date (maybe that's what Victor has done?) and make sure the test > coverage is in place (I'm not sure the status of this?). Test coverage is ~44 test cases. There are currently 2 known problems in the code from a 'correctness' standpoint, and there is a ton of refactoring that needs to be done before it should be considered for merging into the trunk. The code is *messy*. Writing schema evolution went hand in hand with me learning how Django's schema generation worked. That said - the modifications are basically: * decomposing a lot of functions in django.core.managemeent so that they're more re-usabl * removing all REFERENCES clauses in CREATE TABLE statements and changed the code to just emit CREATE CONSTRAINT statements. This makes everything more consistent and easier for me to figure out what constraints to remove later if the schema is changed. * rewriting the syncdb function since it missed creating some foreign key relationships sometimes * most of the heavy lifting is in django.contrib.schemaevo - again, it's all Postgresql specific and I just ripped out the code that I wrote into django.core.management and dropped it into django.contrib.schemaevo. Minor changes were made to get my tests to run again. > Maybe someone is already thinking along these lines? It seems like the > branch could benefit from a "champion" who actively pushes it through. If someone wants to open up commit access on the django branch for schema evo, I'll be happy to bring the schema evo code up to date with the trunk. I *do* need help in tidying it up to get it merged back to trunk though. I'm hard pressed for time right now and I could use some help. vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
