Hi Django Committers,
My name is Meet Bhagdev, I work in the Database Systems engineering team at Microsoft in Seattle, WA. My focus is the APIs used to connect to and use Azure SQL Database and SQL Server (MSSQL). Example APIs are ODBC, JDBC, ADO.NET, etc.
We’d love for Django users to have a solid option to use MSSQL and Azure SQL if they wish, and it would be great to make this option a reality. Our goal is to partner with committers like yourself to bring first-class support for MSSQL to Django. We want to bring the benefits of Django to millions of existing MSSQL and Azure SQL customers as well as folks that would like to evaluate us as a database option for Django.
I have been in touch with Tim Graham and Russell Keith-Magee related to us building such support. We are prepared to make the engineering investment required on our end and to work with the Django community to make this happen, the right way. We are willing to do all the heavy lifting, but we do need your help and guidance.
At Microsoft we have an existing program for bringing partners and eco-system developers to Seattle, WA, all expenses paid, and we’d like to extend this to the Django committers. This would be a great way to get started. We would love to get a group of you here during our October workshop. The idea is to get developers from both sides to meet and learn from each other—Django and Microsoft.
Please reach out me at me...@microsoft.com or give me a call on +1 425 722 5342 if you would like to attend. Would love to get you more details.
Sincerely,
Meet Bhagdev | Linkedin | Github
P.S. This is not a sales pitch; we are excited about bringing the benefits of Django to our customers.:)
We’d love for Django users to have a solid option to use MSSQL and Azure SQL if they wish, and it would be great to make this option a reality.
On Saturday 22 August 2015 13:28:31 Aymeric Augustin wrote:
>
> There isn’t such a clear story for running Django on Linux. This led me to
> write https://github.com/aaugustin/django-pymssql. Alternatives include
> https://github.com/denisenkom/django-sqlserver and
> https://github.com/lionheart/django-pyodbc.
There's also django-pyodbc-azure, a fork of django-pyodbc (actually, the current django-pyodbc is also a fork of the original project, which has been discontinued). I took the liberty to forward the message to that project.
Shai.
I agree it would be great to get some help running the Django tests on Windows. I run them in a local virtual machine every so often, but I would love to be able to delegate fixing Windows issues. Meet, can your team provide ongoing help with fixing Windows-specific issues in Django, even if they aren't related to MSSQL/Azure? That is something where we've had a hard time finding volunteers to help with and is obviously important if we want to claim 1st-class support for Windows.
I don't have any experience with MSSQL/Azure, but I could probably attend the October 13-15 event at Microsoft if you think my participation would be valuable and if the DSF were to approve the time commitment as part of the fellow duties.
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/be75654f-619f-4d59-ac0d-24d50de3d6f9%40googlegroups.com.
The goals of the October workshop are to:
1) Get to know each other and begin building a relationship
2) Get in a room with Microsoft developers and discuss the current landscape
3) Work on half day coding sprint(s) with Microsoft developers to get started with contributions
4) Establish a plan for how Microsoft can best contribute to Django, and ensure we have great integration between Azure SQL and MSSQL and Django by maintaining our contributions
The key takeaway is that we want to contribute to existing solutions to improve the Django and MSSQL/Azure SQL story. To do so we want to understand the current landscape, the gaps, and the next steps to make this happen (the right way).
We are currently in the planning stages and would love to get feedback. What do you think about the goals mentioned above? Is there anything you like to add/remove?
We can definitely make attending via Skype an option for attendees unable to make it in person.
Best,
Meet
Hi all,
On Fri, Aug 21, 2015 at 2:39 PM, Meet Bhagdev <meetb...@gmail.com> wrote:
> Hi Django Committers,
>
>
>
> My name is Meet Bhagdev, I work in the Database Systems engineering team at
> Microsoft in Seattle, WA. My focus is the APIs used to connect to and use
> Azure SQL Database and SQL Server (MSSQL). Example APIs are ODBC, JDBC,
> ADO.NET, etc.
(sorry for possibly repeating things folks have already posted to this thread)
Meet: Is this list of APIs the final and full one?
This is definitely not a final and full one. We have actually started endorsing pymssql and FreeTDS to our Linux and Mac customers who want to use Azure SQL.
We have also created documentation that lets customers use pymssql on
1. Windows: https://azure.microsoft.com/en-us/documentation/articles/sql-database-develop-python-simple-windows/
3. Mac: https://azure.microsoft.com/en-us/documentation/articles/sql-database-develop-python-simple-mac-osx/
Because there is work being done on a different stack, the one formed by :
* FreeTDS (http://www.freetds.org/ GPL licensed) which implements the
wire-level TDS protocol.
* pymssql (http://pymssql.org LGPL licensed) -- Python bindings for
FreeTDS which implements the Python DB-API 2.0. I'm part of the team
maintaining it
* django-pymssql (https://github.com/aaugustin/django-pymssql ,
MIT-licensed) which was created by Aymeric Augustin and depends on
pymssql plus ...
* django-mssql (https://django-mssql.readthedocs.org/en/latest/ ,
MIT-licensed) which was created by Michael Manfre
Michael, Aymeric and me are Django development team members.
Personally, I've been working on stabilizing the lower layers by
following a "yak shaving" non-strategy:
We (the pymssql team) realised the official pymssql Windows binaries
(in particular the FreeTDS libraries) we published when releasing
pymssql 2.1.1 don't link in a SSL implementation and so they aren't
usable to actually connect to Azure even if the pymssql code iself has
such ability.
I looked around and it seems like this problem was fixed on this page by Christoph Gohlke from University of California, Irvine: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pymssql. I downloaded pymssql from here and it seemed like it links the SSL implementations. I also documented the procedure here: https://azure.microsoft.com/en-us/documentation/articles/sql-database-develop-python-simple-windows/
This, plus the fact that the manual process of creating the actual
matrix of Windows deliverables is a bit tedious led me to try using
the AppVeyor.com hosted Windows CI platform (free for open source
projects) to test and actually build the binaries. The work in
progress on this can be seen at
https://github.com/ramiro/pymssql/tree/appveyor and
https://ci.appveyor.com/project/ramiro/pymssql
(When working on pymssql 2.1.1 at some point I created a free Azure
account with my credit card, tested (on Linux) the pymssql
implementation of connection changes needed to get it to work against
Azure's SQL Server and cancelled it before it started billing.)
So, this led me to start contributing to FreeTDS so to get it back to
build cleanly on Windows (work partially included with the 0.95
release back in June) and to also get it built/tested using
AppVeyor.com using the experience gained with pymssql. This has been
already merged in the current FreeTDS development code and allows the
maintainer and contributors to work without access to Windows/SQL
Server licenses (my case).
- https://ci.appveyor.com/project/freetds/freetds
- https://github.com/FreeTDS/freetds/commit/3db5caa48f281f3558d4031cb5a0f0d8e8eef28c
I know MS dropped support of the DB-Library (and hence the API it
provides, of which FreeTDS is a open source implementation) back in
the SQL Server 2005 times. That's why I ask if this stack has any
chance of getting some support from Microsoft.
We are very much looking at providing support(as you can tell) from our documentation mentioned above. We are currently in the prioritization stage and would love to discuss some of the things you need support for. As for now, we feel Django is a good place to start, as there is customer demand and we are falling behind. Would have a document which highlights the todo feature list where you need help on? I can pass it on to my team to get some responses so that we can get the ball rolling.
Personal motivation for this is simply to get Django (running on
Linux) + SQL Server to be a viable choice, even when I currently have
no actual need of this. I was one of the two developers behind the
original django-pyodbc project which had reached "almost full Django
test suite passing" status back in the Django 1.0 & 1.1 (2008-2009)
times, but abandoned it when discoverd (by logging the traffic with
SQL Servr tools) that the combination of pyodbc + Linux ODBC stack
meant the queries were sent twice to the DB server, see
https://code.google.com/p/django-pyodbc/issues/detail?id=16 . This is
also why I started considering a FreeTDS-based solution a better
technical choice.
I'm posting a message to the FreeTDS mailing list later today pointing
to Meet's post which opened this thread.
On 13 sept. 2015, at 01:48, Tim Allen <fli...@peregrinesalon.com> wrote:
- We have a test suite performing table creates / destroys, basic CRUD operations, stored procedure execution, and more against both pyodbc and pymssql.
- pymssql outperforms pyodbc significantly against SQL Server, especially on SELECT and INSERT operations.
- pymssql on Linux offers no stable Django options, as noted throughout this thread.
- pyodbc offers several options.
- we initially started using django-pyodbc (lionheart on GitHub), which worked but required quite a few tweaks to the settings.
- we moved to django-pyodbc-azure, which we found a much easier install / Django DATABASES {} configuration, and is kept up to date in a timely fashion.
Did you mean “pyodbc outperforms pymssql”? Or did you go with pyodbc despite lower performance? (Or did I misread that?)
- django-pymssql is basically django-mssql on Linux. We could debate whether django-pyodbc-azure is more stable than django-mssql. There’ve been a bunch of forks over the years.
I’m not going to argue it further because I would inevitably sound like I’m tooting my own horn which isn’t my intent. I will just say that the picture isn’t all that clear.
From the perspective of someone who works on Django’s internals, I believe django-pyodbc-azure could use a review of how the Django database backend API is implemented.For example, looking at the new transaction APIs I introduced in 1.6, I see that it commits or rolls back implicitly in _set_autocommit. At best that’s weird and useless, at worst a data corruption bug.Nothing that couldn’t be fixed, but just because the code works doesn’t means it handles edge cases well. django-mssql probably fares a bit better since its author cooperated with and eventually joined the core team.Thanks to the abstraction provided by the Python DB-API, it should be quite easy to port code implementing Django’s database backend API between django-mssql and django-pyodbc-azure anyway.
Hi Meet,
I was wondering....
1. If you have any progress updates since your last message?
Yes, engineers on my team I are currently ramping up on the three Django-SQL Server adapters
2. If you have any further details on the schedule for the time in Seattle in a week and a half? (including video conference details for those unable to attend in person)
3. If myself or the other attendees should do anything to prepare for the meetings?
Here are some things that you should prepare before coming to Seattle.
-
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8faec72f-c5ab-4913-b852-76520f3b5ac9%40googlegroups.com.Visit this group at https://groups.google.com/group/django-developers.
--
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/adc9ef36-50da-4ca3-bd68-933f6314f7f4%40googlegroups.com.
Hey Tim,
We are continuing to
follow up with Michael and have reached out to Michiya as well. We have
not abandoned the idea of providing engineering resources either, and are still
working out the logistics with Michael as he will help direct our efforts. We
are syncing again in mid-April to discuss the next steps; we are hoping to
start identifying a plan, come up with a proposal and start working on this
shortly after.
Regards,
Vin
--
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/8258f170-8f10-45fc-a1d3-9551efca6d1c%40googlegroups.com.
We are still waiting for a reply from Microsoft. They're a large company, so understandably, it takes a little while.
For now, if people need to get onto Django 2.2 for long term support (which will last until April, 2022), you can use this package:
https://github.com/ESSolutions/django-mssql-backend I've been running it in production for months without incident. Of course, YMMV.
If Microsoft and/or the DSF end up wanting to bring support under the Django umbrella, the django-mssql-backend
repository is a possible starting point, IMHO.
The django-mssql-backend
is currently being developed and support for Django 3.0 is being worked on: ESSolutions/django-mssql-backend#18
Regards,
Tim
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/188ccc39-4675-45f1-8303-ed2b93d51dfcn%40googlegroups.com.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a531fb44-4a5c-48f3-b28c-d78e3419141fn%40googlegroups.com.
Please keep in mind that Phase 2 is something that might never happen. We have a tendency to not bloat Django and there is no reason why a database backend cannot live outside of core.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/73a54032-b179-4c42-b16c-155c1fc3690en%40googlegroups.com.