I started a new page off the old https://code.djangoproject.com/wiki/SchemaEvolution ( https://code.djangoproject.com/wiki/SchemaEvolutionDesign). It's not complete at this point, I just did a brain dump of what I remembered hearing in the past. Sounds like I'm not TOO far off with my memory.
Also, is the following the thread you are thinking of? http://groups.google.com/group/django-developers/browse_thread/thread/6239a63c9ad874b5/ Thanks in advance, Joe Tennies Also, Russell, I didn't know you were the one behind django-evolution. I may need to pick your brain at some point. I have a couple ideas I'd like input on, but I'm not quite ready yet. Now I wish I had tried harder to get to PyCon this year, but work was supposed to be quite hectic this week. My goal is to On Sat, Mar 10, 2012 at 3:16 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > 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. > > -- Joe & Anne Tennies tenn...@gmail.com -- 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.
