django-mssql present and future

[Michael Manfre]

There are two parts to this email. First relates to the current state of django-mssql. A version of the backend that supports Django 1.8 will be released in the next few weeks. I apologize for the delay, but my ability to focus on the project was basically non-existent for nearly a year due to personal reasons. The backend is currently failing some of Django's test suite and will likely be released before all of the issues are resolved. The biggest unresolved issues right now relate to certain schema migrations and some failing tests related to prefetch related that I haven't had time to investigate yet. I plan on releasing with a list of known bugs, so if you use this backend, please test the latest commits against your project and let me know if you run in to any issues. Post your found errors on the django-mssql issue tracker [1]. I will not release if there are any data corruption or other blocking level bugs. I'm planning this to be the last major release using adodbapi and the underlying ADO drivers.

[1] https://bitbucket.org/Manfre/django-mssql

Moving forward, django-mssql will be rewritten from scratch to use the Microsoft developed ODBC drivers. These drivers are officially supported by Microsoft and will be cross platform; Windows and Linux support exists and OSX support is currently being worked on. Despite using ODBC drivers, this backend will specifically target MSSQL to take advantage of any features or performance improvements that are possible, and to reduce the support overhead of working against any random database that provides an ODBC interface. Microsoft has stated their willingness to contribute engineering resources towards this backend.

I'd like this soon to be created repo to live under Django's github account and to start the conversation about if this is desirable and what that means for the backend and Django.

Why start from scratch? Sometimes the slate needs to be wiped clean to remove mistakes of the past. Django-mssql has accumulated a lot of crufty code over the years for various reasons. The existing ODBC backends are in various states of support with slightly differing goals; generic ODBC, Azure specific, etc. To me the most important reason is, I want to start from scratch to help document what is involved with creating a database backend.

One concern that has been previously raised relates to handling regressions. It is my expectation that individual commits to Django would be allowed to break the backend's tests, but that they will be resolved before release.

If you have questions related to MSSQL or what are the expectations for having an officially support Django database backend, please share them.

Regards,

Michael Manfre

[Aymeric Augustin]

Hi Michael,

Thanks for this initiative!

I like the idea of hosting this new project in the Django organization. I think there’s a lot of value in having a good SQL Server backend for Django, implemented according to Microsoft’s recommendations, and little reason to encourage competition in this space — there aren’t that many ways to implement such a library.

However I’m wary of deciding that a non-existent-yet library is the endorsed solution for using SQL Server from Django. It may be best to wait until it has reached feature parity with django-mssql and received some amount of real-world testing to move it there.

Best regards,

-- 

Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBsj6SGFqwKR7NFUMb0taExD8LGRcJtU7PPqNvcv5GvPtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Marc Tamlyn]

I'm definitely a fan of doing things under the /django banner. I think so long as we make it clear that this is in development then it shouldn't matter about feature parity - especially as django-mssql won't have a version supporting 1.9 or 1.10 anyway.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/71F893D6-CFB8-480F-9854-AA92ACA4E969%40polytechnique.org.

[charettes]

Hi Michael,

> To me the most important reason is, I want to start from scratch to help document what is involved with creating a database backend.

I agree, such documentation is definitely lacking and even if it wont be commonly used it's invaluable for the rare developers needing it.

Are you planning to include it in the official Django documentation?

Exciting stuff,
Simon

[Michael Manfre]

Aymeric wrote:

However I’m wary of deciding that a non-existent-yet library is the endorsed solution for using SQL Server from Django. It may be best to wait until it has reached feature parity with django-mssql and received some amount of real-world testing to move it there.

Regarding feature parity, the initial commit of this non-existent-yet library will have as many supported features as django-mssql on Django 1.9 and 1.10. :P

The pre-release code will need to be hosted publicly to allow the Microsoft engineers to contribute (and anyone else willing to do so). Having to host elsewhere and then move it relatively soon afterwards will likely cause confusion and unnecessary overhead. When I moved django-mssql from google code to bitbucket, I was fixing links across the internet for the next ~12 months.

Do we want Django to only ever endorse established/mature projects? Or should there be flexibility to endorse people (and companies) willing to implement a solution. 

The current case for the SQL Server backend might be non-standard in that it's really a continuation of the django-mssql project, albeit as a rewrite with backing by Microsoft. I can't imagine the Microsoft supported backend not being the Django endorsed one.

 

Marc wrote:

I'm definitely a fan of doing things under the /django banner. I think so long as we make it clear that this is in development then it shouldn't matter about feature parity - especially as django-mssql won't have a version supporting 1.9 or 1.10 anyway.

I like to think that I do a good job of documenting whether or not I intend a specific bit of code to be ready for production. This would obviously carry over for the initial build up and future pre-release branches.

On Fri, May 27, 2016 at 10:37 AM charettes <chare...@gmail.com> wrote:

I agree, such documentation is definitely lacking and even if it wont be commonly used it's invaluable for the rare developers needing it.

Are you planning to include it in the official Django documentation?

I have no strong feelings either for or against it being in the official Django documentation. I've been wanting to put together a talk about creating a database backend and that will likely be the first pass at the documentation.

Regards,

Michael Manfre

[Aymeric Augustin]

Hi Michael,

On 27 May 2016, at 20:44, Michael Manfre <mma...@gmail.com> wrote:

> Regarding feature parity, the initial commit of this non-existent-yet library will have as many supported features as django-mssql on Django 1.9 and 1.10. :P

Fair enough :-)

> The pre-release code will need to be hosted publicly to allow the Microsoft engineers to contribute (and anyone else willing to do so). Having to host elsewhere and then move it relatively soon afterwards will likely cause confusion and unnecessary overhead. When I moved django-mssql from google code to bitbucket, I was fixing links across the internet for the next ~12 months.
>
> Do we want Django to only ever endorse established/mature projects? Or should there be flexibility to endorse people (and companies) willing to implement a solution.

Actually I’m in favor of putting the SQL server backend in its own repository in the django organization (and also of splitting the Oracle backend in a separate repository, but that’s another story).

I’m just slightly worried that we don’t have a well defined rule and that we may refuse this privilege to other projects for seemingly arbitrary reasons. (The key word is “seemingly”.)

Until now, we haven’t managed to define what the rules for putting a project in the django organisation on GitHub are.

> The current case for the SQL Server backend might be non-standard in that it's really a continuation of the django-mssql project, albeit as a rewrite with backing by Microsoft. I can't imagine the Microsoft supported backend not being the Django endorsed one.

There’s a precedent, namely with MySQL: the Oracle supported backend isn’t the Django endorsed one :-) However, I suspect Oracle built it quite some time after Django built its own, so that’s a different situation.

Best regards,

--
Aymeric.