On Thu, Mar 7, 2013 at 8:13 PM, Russell Keith-Magee <russ...@keith-magee.com > wrote:
> I completely agree with Jacob's analysis of the status quo, and I agree > largely with his position on having MSSQL in the core. > > I'd have no problem seeing MSSQL in the core - it's at least as high > profile as Oracle, and although the demand for a MSSQL backend is > restricted to a particular subset of the community, there is at least > *some* demand for it to exist. Having MSSQL in core would allow us to hold > our head high and say we support Microsoft platforms. Microsoft is even a > member of the DSF at this point, so they're at least notionally interested > in Django as a platform. > /slightly off topic I didn't realize they were a DSF member. I have been wanting to set up Jenkins to run the test suite on Windows with the ultimate goal of getting its results added to ci.djangoproject.com. Knowing that Microsoft is a DSF member will probably help gain access to a VM on Azure to make that a reality. I've so far managed to get an introduction to a PM on one of the Azure teams to help get a more direct answer to some Django, Windows, and SQL problems that have been raised to my attention. /back on topic The maintenance burden is the problem. Historically, we've already had to > *remove* a MSSQL backend because of bit rot (see [1]) - this isn't a > pattern I want to repeat in the future. I don't want to add a backend to > core unless I'm *certain* that it will see long term maintenance. > > [1] https://github.com/django/django/commit/c30a050e41 > The demand for MSSQL would probably increase if it were included in core because companies could be more confident about its ongoing support. There are three options for using MSSQL with Django; django-pyodbc, django-mssql, or write your own. The third option is not really a viable option for most users. django-pyodbc is cross platform, but not updated very often and has limited stored procedure support. The official repo on Google code was last updated in 2011, but there is a github fork with its last commit 8 months ago. django-mssql is actively maintained and will be for at least the next few years because it's used for my employer's production site that is critical to business operations. The backend also supports stored procedures almost to the same extent as a Windows business application. The only real downside to the backend is that it only works on Windows, reducing its usefulness to a much smaller, but growing, minority of Django users. If Django wants to "hold [its] head high and support Microsoft platforms", then I'm willing and capable of helping out with MSSQL and Windows support. The only real caveat is that my employer needs me to maintain a certain level of stored procedure functionality, so if MSSQL were included in the core by using django-pyodbc instead of django-mssql, I would only be able to commit personal time toward maintaining it, instead of also being able to set aside business hours. There is, however, a possible middle ground, following the example set by > Flask: we introduce to Django a list of "officially recognised" extensions. > These extensions are still maintained as external projects, but the core > team promise to include these projects as part of the testing regimen for a > release. If the MSSQL backend were recognised like this, we would run the > full Django test suite against the MSSQL backend, and if that testing > revealed a bug in the test suite which was identified as being due to a > change in Django's codebase, that bug would be a release blocker (Bugs in > the backend itself would still be the backend's responsibility, and not > release blocking on Django) > This is sort of the idea I had in mind for backends while I was typing up this proposal. You articulated it better than I did. A main problem I now see with it is if the ownership of a bug cannot be mutually agreed upon between Django and the extension, then this could cause doubt about what it really means to be "officially recognized". Regards, Michael Manfre Since DjangoCon, I now hear the email author's voice when reading some of these emails. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
