I would love to volunteer for the project of MSSQL support. It happens that django-mssql uses a fork of my adodbapi v2.1 code. I pulled those changes back into the main branch of adodbapi (and did a lot of useful refactoring thanks to the good work done on the fork) at version 2.3. Apparently the announcement of that did not get to the right people, since the peek I just took shows the forked code still in use.
The two major obstacles I can see to MSSQL support (either as part of the core or as a supported add-on) are: 1) lack of an MSSQL server and test bed which the maintainers can use on a regular basis. 2) django-mssql is not Python 3 ready. The first of those obstacles has already been addressed. The second is fairly easy. I suspect (not having examined the code) that most of the Python3 problems will be found in the old fork of adodbapi. If we simply change django-mssql to call the current version of adodbapi all of that goes away. The current version is already present on their Python library, I am sure, because it ships as part of pywin32, which is also a prerequisite for the V2.1 code. Yes, all of pywin32, including adodbapi, runs on Python 3 -- has done for years. Would there be a "market" for a supported version of django which runs MSSQL? Does the bear live in the woods??? Take, for example, my present employer. (I escaped from the "we are a strictly Microsoft shop" employer where I used to work.) We here at eHealth Africa use Ubuntu and postgres as much as possible. But it's not always possible. For example, part of the project I am working on now will use ArcGIS -- which only runs on Windows. Then one of our funding organizations (ever heard of the Gates Foundation?) required us to host a database on an MSSQL server. We bit the bullet, bought the licenses (it's their money, after all) and set up the SQL server. Do you think we want to use django on it? Huh? If it will help kill polio, we will use anybody's software. As to the question of moving MSSQL into the core, or moving the two Oracle dbs out of it (you do remember who owns MySQL?) -- I would suggest pulling all non-FOSS out. Would you accept my patches to the core? Of course not. and you should not: I don't know django well enough. Would you accept my patches to an MSSQL back end? I should hope so. There has been talk. from time to time, about extending django to have more multi-database capability. The changes that would be needed to run three different db engines from outside the core would easily extend to other engines. People tend to think of ADO as only talking to Microsoft databases. Nothing could be farther from the truth. When maintaining adodbapi, I normally test against MS-SQL Server, Microsoft "Jet" (a.k.a. ACCESS), MySQL, and postgres. I have also personally used it to get data from IBM DB2, an Active Directory server, and a .csv file. If some idiot has written an odbc driver for it, I will let you read it from Python. Build the hooks. -- Vernon Cole On Thursday, March 7, 2013 8:24:00 PM UTC-7, Michael Manfre wrote: > > > > On Thu, Mar 7, 2013 at 8:13 PM, Russell Keith-Magee < > rus...@keith-magee.com <javascript:>> 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.
