Check the edit dates on that wiki -- most of the content on that page is historical, reflecting discussions that were happening over 3 years ago. There have been many more recent discussions.
Sincere apologies. The page says "Last modified 10 days ago". I thought it was pretty recent and didnt check the history. I can see that you're obviously enthused by this project, but as it stands, I can't say this is a very compelling proposal. * It ignores the most recent activity in the area (last year's GSoC, in particular) I did go through last year's proposal but it was in conflict with the above wiki page. I sided with the one that *appeared* more recent but was actually 3 yrs old :( Thanks for taking the time to submit this proposal. I'd encourage you to have a second swing at this. Read the recent discussions on the topic; take a look at last year's GSoC proposal; and spend some time elaborating on the details that I've highlighted. Thanks. I will submit a revised proposal ASAP. Also I needed help/clarifications regarding some points: I don't think you're going to be able to ignore raw SQL migrations quite that easily. Just like the ORM isn't able to express every query, there will be migrations that you can't express in any schema migration abstraction. Raw SQL migrations will always need to be an option (even if they're feature limited). Andrew's thread[1] also mentions - "backends will always be able to generate SQL for operations, but it won't necessarily be runnable (things like index names can only be resolved at runtime, so you'd get code like "DROP INDEX <<User.username-index>> ON users;"." [1] https://groups.google.com/forum/?fromgroups#!topic/django-developers/usFXJvpelmI Am I correct to assume that the plan is to allow migration files in python as well as pseudo-SQL like above? In that case, I think will concentrate on just the core part of migrations API and nothing else as far as GSoC is concerned. Another query: Andrew's thread above also mentioned: Some of these operations are already mostly implemented (add_table, add_index, etc.) in backends' creation modules, but they'll need a bit of rearranging and separating into a full public API. I also plan to modify them to take model names and field names, instead of table names and column names, so the API is exclusively using the Django model layer to represent changes (there's a possibility that some changes make sense for schemaless databases as well, specifically renames, so it's best not to tie it directly to relational databases). As it happens xtrqt last year had implemented, documented and tested the migrations API for at least SQLite[2]. However he used explicit table and column names in his API methods. Obviously he put the task of table name translation on the API caller. Is there any consensus on the API design regarding this point? [2] https://groups.google.com/forum/?fromgroups#!searchin/django-developers/xtrqt/django-developers/pSICNJBJRy8/Hl7frp-O-dMJ * * On Mon, Mar 19, 2012 at 6:32 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote: > On Mar 19, 2:32 pm, Jani Tiainen <rede...@gmail.com> wrote: > > Here I would like to rise my concern - specially being long time Django > > and Oracle user.. =) > > > > First at all everyone can get hands on Oracle Express database, free of > > charge standard Django stuff works in it very well. Geodjango doesn't > > work with it. AFAIK MSSQL is something that is not officially supported > > by Django so that shouldn't be much a problem if it's not touched. > > > > Secondly Django has been in the past very consistent in support of four > > databases: SQLite, PostgreSQL, MySQL and Oracle. All supported pretty > > well as well as possible. I'm aware that doing migrations for all > > databases is a time taking challenge to tackle around all peculiarities > > in different backends. So hopefully that consistency is kept even with > > new features like this. > > I think what was meant in above postings was that it is not needed to > do all the different backends during the GSoC, not that they do not > need to be done at all before commit. > > What is important is that the MSSQL support (or any other 3rd party > backend) is possible to write without core changes. Django's backend > architecture is such that it is unlikely any problems arise, but > nevertheless it is important to verify the support isn't limited to > core backends. > > > And yes, second thing is of course Geodjango part which takes complexity > > to whole new level. > > Handling Geodjango is an important proof that the API is correct. > Geodjango support should be ideally a completely separate patch to > contrib, without any need for core changes. Of course, doing all of > this in the GSoC is just too much, but trying to do a little part > (preferrably the _hardest_ part) is an important verification that the > API is correct. > > My opinion is that in the long term Django should aim for better > support of custom model fields, and having good support for these > fields in schema migrations is one important part of that. Geodjango > is an interesting example of hard to do custom model fields > > - Anssi > > -- > 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. > > -- Kushagra SInha B. Tech. Part III (Pre-final year) Indian Institute of Technology Varanasi Contact: +91 9415 125 215 -- 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.
