Hi Cristiano, I support a bunch of developers on Windows (and Mac and Linux). You've probably heard this before, but Vagrant has really been a game changer for us. We're a RedHat shop, so I've built a CentOS vagrant box our developers can easily spin up for development purposes. It really helps for several reasons: they're developing on a Linux flavor as close to the production environment as possible, and have root access on their local VM which allows them to test new packages, configurations, and so on. It has improved our development process by leaps and bounds. For my stuff, I've developed a Vagrant / Linux / Python 3 / Django / FreeTDS - SQL Server box. I don't know if it might help you out, but feel free to have a look here: https://github.com/FlipperPA/django-python3-vagrant
I'm still hoping this project moves forward; it'd be great to have closer-to-native support. Regards, Tim On Thursday, January 28, 2016 at 1:09:41 PM UTC-5, Cristiano Coelho wrote: > > Tim Allen, > > What you said about compiling the C dependencies on a similar machine and > then upload it all together indeed works (it was one of the options) but > caused some other issues (ie: we usually develop on Windows, and also the > compiled libraries are very platform specific) and performance was really > not that important in this case. But just letting you know that your idea > works most of the time if you are willing to take the extra work. > > El jueves, 28 de enero de 2016, 12:48:29 (UTC-3), Tim Allen escribió: >> >> Thanks to everyone for their efforts; my workplace has a mix of SQL >> Server and PostgreSQL, heavier on the SQL Server side. Due to some groups >> reliance on SSIS and tight SQL Server integration with data vendors, that >> isn't going to change any time soon, so this is project is one we're >> following closely as well. We've tried to contribute by way of feedback, >> testing various configurations with various drivers, some documentation and >> a minuscule amount of code contribution. >> >> In case this anecdotal evidence helps anyone in the meantime, the stack >> we've found most reliable these days (from RedHat / CentOS, at least, but >> also partially tested on Ubuntu) is: >> >> - FreeTDS 0.95 (supports TDS version 7.3) with unixODBC. We tried the >> Microsoft provided ODBC driver, but ran into quite a few issues, >> particularly with multi-threading. >> - pyodbc 3.0.10. pyodbc just works. We get slightly better performance >> with pymssql, but have found pyodbc to be more frequently updated and >> rock-solid. The performance upgrade didn't warrant using pymssql in our >> case, but is worth mentioning. >> - django-pyodbc-azure. This is kept up to date with Django and Python >> release versions, and works with the least amount of configuration tweaking >> that we have found. >> >> We're on a mix of RHEL/CentOS 6 and 7, and have gotten this stack running >> reliably up to v7.2. YMMV, of course! >> >> As for the C dependencies, have you considered building the C binaries >> necessary on another server, and then just including them as part of a >> wheel (or something like that) for installation were you couldn't install? >> This sound like a perfect use case for a temporary vagrant box you could >> blow away after compiling. Just a thought that might give you the >> performance you need without stepping on anyone's toes. >> >> On Wednesday, January 27, 2016 at 12:15:48 AM UTC-5, Cristiano Coelho >> wrote: >>> >>> I'm interested in the progress of this as well :) >>> >>> Sorry I didn't read through all the posts, mostly the first ones about >>> the idea. >>> >>> I would like to know, have you guys decided on which adapter to use? I >>> have had a project where we needed to connect to SQL Server from a linux >>> machine (actually amazon lambda) and even worse, we couldn't install any >>> library with dependencies on C code, so we used one that was implemented in >>> pure python that worked very well (pytds if I'm not wrong), with ofcourse, >>> not the best performance. >>> Why do I tell this? Because even if you want django to run on SQL >>> Server, it doesn't really mean you want to run it on a Windows machine, >>> actually, that would probably be a terrible idea (no ofense), since apache >>> works horribly bad on Windows, and Linux is atually the best OS to run a >>> web server with python code (either nginx or apache). So please keep this >>> in mind when chosing a connector, since if it has C dependencies (which it >>> will probably have, since the pure python ones are quite slow). >>> >>> About if you need different connectors for Azure or SQLServer, I'm >>> 'almost' sure you don't, we use azure or other cloud based sqlserver >>> deployments with no problem with standard sqlserver connectors. >>> >>> So basically, do not aim this towards making django more Windows >>> friendly, but rather the actual SQL Server backend. >>> >>> El lunes, 25 de enero de 2016, 22:59:07 (UTC-3), Fabio Caritas >>> Barrionuevo da Luz escribió: >>>> >>>> is there any update about the progress of this? >>>> >>>> -- >>>> Fábio C. Barrionuevo da Luz >>>> Palmas - Tocantins - Brasil - América do Sul >>>> >>>> >>>> >>>> Em terça-feira, 13 de outubro de 2015 18:12:55 UTC-3, Tim Graham >>>> escreveu: >>>>> >>>>> If anyone is interested in listening in on the meetings with Microsoft >>>>> engineers (Wednesday and Thursday 9am-5pm Pacific), let me know and I'll >>>>> send you the Skype link. >>>>> >>>>> On Friday, October 2, 2015 at 11:53:17 AM UTC-7, Meet Bhagdev wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Thursday, October 1, 2015 at 12:32:25 PM UTC-7, Tim Graham wrote: >>>>>>> >>>>>>> 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* >>>>>> >>>>>> >>>>>> - * Django-pymssql* >>>>>> - * Django-pyodbc-azure* >>>>>> - >>>>>> * Django-mssql * >>>>>> >>>>>> * The goal is to have a thorough understanding of what’s good and >>>>>> what’s bad with these adapters before the event. * >>>>>> >>>>>>> >>>>>>> 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) >>>>>>> >>>>>> >>>>>> - *We will have a video conference link for Day 2 and Day 3. >>>>>> Participants interested can join the conference stream from their >>>>>> browser. >>>>>> The conference room mics are only capable to a certain extent. Thus >>>>>> the >>>>>> quality might be a little poor. * >>>>>> >>>>>> >>>>>> - *We are finalizing the detailed schedule this week and will >>>>>> post it on this thread by next Friday. * >>>>>> >>>>>> >>>>>> 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.* >>>>>> >>>>>> *- * >>>>>> >>>>>> >>>>>> - >>>>>> * Have a clear understanding of the things that you need from >>>>>> Microsoft to improve the SQL Server support on Django. We have >>>>>> resources to >>>>>> do the heavy lifting but need guidance. * >>>>>> - * Share with us the issues we can help fix (on the Django >>>>>> side and on the Django-ORM(database) side). * >>>>>> >>>>>> >>>>>> Thanks! >>>>>>> >>>>>>> On Thursday, September 17, 2015 at 3:38:09 PM UTC-4, Tim Allen wrote: >>>>>>>> >>>>>>>> Hey team, as promised, here are the simple tests I put together to >>>>>>>> benchmark pyodbc vs pymssql. Be kind, this was Python I wrote a long >>>>>>>> time >>>>>>>> ago! >>>>>>>> >>>>>>>> https://github.com/FlipperPA/pyodbc-pymssql-tests >>>>>>>> >>>>>>>> I've included example output on the README. Very basic, but useful. >>>>>>>> >>>>>>>> On Wednesday, September 16, 2015 at 11:27:59 AM UTC-4, Tim Allen >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Thanks for all of your efforts, Aymeric, I've been following your >>>>>>>>> project since its inception - I'm FlipperPA on GitHub. >>>>>>>>> >>>>>>>>> On Sunday, September 13, 2015 at 4:59:34 AM UTC-4, Aymeric >>>>>>>>> Augustin wrote: >>>>>>>>>> >>>>>>>>>> Did you mean “pyodbc outperforms pymssql”? Or did you go with >>>>>>>>>> pyodbc despite lower performance? (Or did I misread that?) >>>>>>>>>> >>>>>>>>> >>>>>>>>> We went with pyodbc, despite lower performance. I've been meaning >>>>>>>>> to put the simple tests up on GitHub - making a note to do that this >>>>>>>>> week. >>>>>>>>> >>>>>>>>> At the time we were looking at options, we couldn't find a stable >>>>>>>>> Django option for pymssql. I should have been more clear about the >>>>>>>>> time >>>>>>>>> frame in which we were testing as well; this was right around the >>>>>>>>> time that >>>>>>>>> you first started django-pymssql. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> There is definitely much more to consider now, than when we were >>>>>>>>> first assessing options. I will say I've been impressed with >>>>>>>>> django-pyodbc-azure staying up to date with Django's releases. >>>>>>>>> >>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You certainly know this stuff more intimately that me, I can just >>>>>>>>> relay my experience, and hope it helps! Either way, a driver provided >>>>>>>>> from >>>>>>>>> Microsoft that offers better performance, easier installation and >>>>>>>>> configuration, and more features would be a win for us all. The >>>>>>>>> amount of >>>>>>>>> time I've seen people spend trying to get FreeTDS + unixODBC + pyodbc >>>>>>>>> running is substantial. >>>>>>>>> >>>>>>>>> Thanks again for your efforts - they're very much appreciated, and >>>>>>>>> I'll check out django-pymssql again soon, it has been over a year. >>>>>>>>> >>>>>>>>> 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/ba179d63-1c19-484e-866d-85b8760fdcb6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
