On 10/03/2012, at 1:52 AM, Joe & Anne Tennies wrote: > While, I generally agree with the current approach, especially this close to > release. I'm going to play devil's advocate for a bit. > > Schema migrations have been talked about for quite a while. There are at > least 3 external implementations I know of: South, nashvegas, and > django-evolution. I'm unsure of the status of django-evolution, but the other > two appear quite active.
Django Evolution isn't dead. It's sleeping. It's got lovely plumage, you know... :-) Seriously -- I stopped working on Evolution several years ago. I formally handed over the project to Christian Hammond almost 2 years ago, but this has been mostly for maintenance purposes, rather than active development. For the benefit of posterity, I blogged about the reasons [1]. [1] http://cecinestpasun.com/entries/end-my-evolution/ > A concern in my mind is that all three go off and do things totally different > ways, and the migration path to a common standard is more difficult. > > I love the idea of not choosing a tool to make the migrations, but instead > add to the ability to execute migrations. Now comes the conversation of what > that means. I would love to try to get this in to Django 1.5. A lot of this conversation has already happened, and it has core team approval. Most of these discussions were elaborated in last year's aborted GSoC 2011 project; search the django-dev archives from this time last year to see the details of what was being proposed. The short version: * Add a db.backends module to provide an abstract interface to migration primitives (add column, add index, rename column, rename table, and so on). * Add a contrib app that performs the high level accounting of "has migration X been applied", and management commands to "apply all outstanding migrations" * Provide an API that allows end users to define raw-SQL migrations, or native Python migrations using the backend primitives. * Leave the hard task of determining dependencies, introspection of database models and so on to the toolset contributed by the broader community. Under this approach, South would still need to exist, but it would be a tool leveraging the primitives exposed by Django itself. Over time, more features from South (and any other migration support projects that emerge) could be merged into trunk as the community converged on a feature set or an implementation. One of the big issues that needs to be addressed is testing -- we need to have the infrastructure that allows us to check that migrations have been applied. Arthur Koziel's AppRefactor (a GSoC 2010 project) has some analogous testing problems, so getting migrations into trunk may be dependent on getting the App Refactor into trunk as well. The good news is that the App Refactor also forms the likely stub for fixing the auth.User problem -- but that's a separate discussion. > Now on to the meat of what I really want: > Is there something along the lines of the GNOME design group for Django? > (example: https://live.gnome.org/Design/Apps/Web). I'd love a template for > the wiki or even better an app to discuss these things. If only we had some > web developers ;) So, is there a sanctioned tool already out there? Or should > I start building up a page on the wiki for this? I think most things become > much easier once one gets a blueprint and requirements for what the design > goals are. Especially if one can get an initial "this looks acceptable" by a > core committer before "wasting one's time" because the requirements weren't > even correct. There are some historical examples where we've used the wiki to elaborate on an idea as a precursor to getting a feature into core. https://code.djangoproject.com/wiki/SessionMessages https://code.djangoproject.com/wiki/ClassBasedViews https://code.djangoproject.com/wiki/LoggingProposal https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl (The first two are probably the best examples to follow) There is a wiki page which has been used in the past to discuss schema evolution (which it looks like you've found); however, it's wandered a little off the reservation. There's probably some good material in there still, but if someone is looking at this, it would benefit from some manicuring, and probably a complete reboot: https://code.djangoproject.com/wiki/SchemaEvolution There isn't a specific wiki template that we require -- this is mostly because every project has slightly different requirements. However, the broad format is fairly common: * describe the problem * describe any specific design constraints * describe the possible approaches and their benefits/limitations * list any prior art * list any draft implementations If you want to work on this, I can guarantee that you would have as much support as I and Andrew Godwin (South maintainer and Django core developer) can muster. This is one of the big ticket items missing from Django's core, and I'd *love* to see someone take a serious swing at addressing it. As with every big feature that is "missing" from Django (be it migrations, auth.User problems, or anything else), the issue is almost always finding someone who is willing to do the work -- not just for a day or two, but to actively drive a project for several months. 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
