On Thu, Apr 7, 2011 at 1:47 AM, xtrqt <[email protected]> wrote: > Schema Alteration > ================= >I hope research I've made for > this > proposal will convince you ;)
Consider me convinced :-) This is a solid proposal -- it's a clearly defined need, and the work you have described here sounds like it will be a good match for the GSoC timeline. However, we can't let you get away without asking at least one question [1] :-) [1] http://djangocaptions.com/post/647587573 So: > Prefered way would be to introduce new layer of API, modeled on > South, > which would make use of existing internal functions for generation, > and > functions to be written for alteration. This layer of API would be > frozen > and made almost 'public' with well written documentation, to use in > schema > modyfing apps. > > To sum up we need to develop new layer of API which would allow 3rd > party > applications to create, alter, inspect, drop schema [all meta > operations > on database]. Django doesn't support alterations, and support drop > operation in not consistent way, so these internals should also be > implemented. All cases in which django internally modifies schema > should > also be refactored to use new API. > > For now there are not many references to creation API in Django code. > In fact it is used mainly in ``syncdb`` and ``testserver``. These > two managements command implement the loop that aggregates sql code > needed > to create new model tables. We could imagine refactoring it to use new > API. (API till the first week of GSoC, I believe will be open for > discussion). Can you clarify your approach a little bit here? Are you proposing to completely deprecate the existing backend.creation interface in favor of a new "metaoperations" module? Or are you going to keep the old creation module and introduce a new module that contains the 'missing' operations like rename and alter? Or something else entirely? I know that backend.creation isn't formally a stable API, but it's been around for so long that it shouldn't be changed lightly. Even though it isn't stable, changing the creation API would have consequences -- for example, every external database backend would be broken for 1.4 if they needed to upgrade to use a new creation API. I'm not opposed to deprecating/modifying the existing creation interface if necessary -- I'd just like you to elaborate on why it is necessary, and if there are any mitigation strategies that we can use (such as redirecting the old interface to the new calls) that we can use to help ease the migration process. 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 [email protected]. 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.
