Re: Proposal: Clarify individual members page

[Tim Allen]

I'm of the opinion that if you care enough about Django to investigate 
becoming a member of the DSF, that's enough of a qualification - it is just 
challenging to formalize that into proper text for the website. Maybe two 
changes to encourage people to join:

   - We could tweak *"Running Django-related events or user groups"  *to 
*"Attending 
   or organizing Django-related events or user groups"*.
   - Add a sentence to the end of the first stanza: "The following are 
   Individual Members of the Django Software Foundation. The DSF appoints 
   individual Members in recognition of their service to the Django community. 
   If you would like to join the DSF, we welcome you. Please feel free to 
   self-nominate for membership."

Regards,

Tim

On Monday, November 7, 2022 at 11:12:41 AM UTC-5 cory...@gmail.com wrote:

> Hey Andrew,
>
> Thanks for drafting this language and I think it looks great. As someone 
> who only recently applied after hearing it discussed on an episode of 
> Django Chat[1], I'm all for the goals of making it more encouraging and 
> accessible and think this is a great step in that direction.
>
> Here are a few minor thoughts to specific bits:
>
> Service to the Django community takes many forms. Here are some examples 
>> (non-exhaustive) of categories of work performed by members:
>>
>
> "performed by members" is a little ambiguous as to whether it means "this 
> is how we evaluate applicants" vs "this is what you'll do if part of the 
> DSF". Since I think the intention is the former it might make sense to 
> change to something like:
>
> *Service to the Django community takes many forms. Here are some 
> (non-exhaustive) examples of the categories of work that might qualify as 
> "service":*
>
> Borrowed the list of categories from Andrew Godwin's DEP for the update to 
>> the technical board. Per Tim's recommendation, do we want to include 
>> anything about the review process?
>>
>
> When I applied I didn't (and still don't, really) have any visibility into 
> the process, so it wasn't a deterrent for me, personally, but I think 
> having information certainly wouldn't hurt. My two cents would be good to 
> put something in, but not necessarily if it slows down/stalls this change 
> if for whatever reason that isn't super easy, since I think this represents 
> an improvement on its own.
>
> Also, I'm a little unsure about that last bit about applying, but I wanted 
>> to put something encouraging to folks to apply. Happy to reword that if 
>> someone has a better suggestion. I'd prefer that to having a full rubric 
>> for membership on this page, primarily because I think it would be very 
>> difficult to nail that down because the work that folks perform can be so 
>> disparate (must have run X django meetups, or triaged Y tickets). 
>>
>
> Definitely agree a rubric would cause more problems than it would help at 
> this stage. The goals of rubrics in terms of increasing objectivity and 
> reducing bias are great, but as applied to the already-squishy definition 
> of "service to the community" it doesn't seem like a good fit here.
>
> Finally, this is wildly out of scope, but it may make sense to (either 
> here or separately) attempt to create a bit more content about what it 
> means to be an individual member of the DSF. That information is also 
> somewhat lacking, and having it somewhere may encourage more people to 
> apply. One possibility could be to link to one of the recent conference 
> talks[2][3] on the DSF. But wouldn't want that discussion/information to 
> slow down this change. 
>
> cheers,
> Cory
>
> [1] https://djangochat.com/episodes/read-the-docs-eric-holscher 
> [2] https://www.youtube.com/watch?v=Z_e-QoeZwEM
> [3] https://www.youtube.com/watch?v=uJnaEZkoVTg
>  
>
>> On Thursday, October 27, 2022 at 10:03:48 AM UTC-4 carlton...@gmail.com 
>> wrote:
>>
>>> That would be awesome, yes. Fresh eyes likely see more clearly :) 
>>>
>>> And equally. :) 
>>>
>>> Thanks. 
>>> C. 
>>>
>>> On Thursday, 27 October 2022 at 15:28:09 UTC+2 acm...@gmail.com wrote:
>>>
 Regarding Carlton's points, that does clarify, and I agree about the 
 open ended qualifiers. I also agree with Tim's points. I'm not sure we 
 need 
 another membership level (I'm not opposed, though). Rather, I think making 
 the current page more transparent will help more folks feel welcome and 
 hopefully get more folks (who do fit the criteria) to apply.

 If someone wants to draft new language, that would be great. If not, I 
 may have some time next week to try.

 Thanks,
 Andrew

 P.S. Great meeting both of you at Djangocon last week!
 On Thursday, October 27, 2022 at 7:41:15 AM UTC-4 schill...@gmail.com 
 wrote:

> Hi Carlton,
>
> I think I might have been one of those people mentioning the lack of 
> definition around the membership requirements. It has held me back from 
> applying (finally sent one in 

Re: Improvements to the startproject template

[Tim Allen]

 that such 
>>>>>> apps are tightly coupled
>>>>>> - with manage.py still in the root folder, you don't need to cd into 
>>>>>> any folder to start working
>>>>>>
>>>>>> I use it all the time.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Olivier
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le mer. 20 avr. 2022 à 18:50, Tom Carrick  a écrit :
>>>>>>
>>>>>>> I prefer Adam's suggestion in the forum post as it lets you 
>>>>>>> namespace everything under your project name nicely and avoids package 
>>>>>>> name 
>>>>>>> collisions, although it doesn't solve the problem of having two 
>>>>>>> directories 
>>>>>>> with the same name by default.
>>>>>>>
>>>>>>> That said, either would be an improvement on what we have so I'm in 
>>>>>>> favour of either approach over doing nothing.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Tom
>>>>>>>
>>>>>>> On Wed, 20 Apr 2022 at 16:49, John M  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I do exactly this for every new Django project, so it's +1 from me 
>>>>>>>> as well.
>>>>>>>>
>>>>>>>> John
>>>>>>>> On 20/04/2022 12:01, da...@springbourne-tech.com wrote:
>>>>>>>>
>>>>>>>> +1 for me - this would be really useful.
>>>>>>>>
>>>>>>>> On Monday, April 18, 2022 at 9:02:02 PM UTC+1 pyt...@ian.feete.org 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Tim,
>>>>>>>>>
>>>>>>>>> This feels like a good idea to me.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Ian
>>>>>>>>>
>>>>>>>>> On Mon, 18 Apr 2022 at 18:17, Tim Allen  
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Greetings, friends! 
>>>>>>>>>>
>>>>>>>>>> I've issued a PR that makes two changes to the 
>>>>>>>>>> `startproject` template:
>>>>>>>>>>
>>>>>>>>>>- instead of putting configuration files such 
>>>>>>>>>>as `settings.py`, `wsgi.py`, and the 
>>>>>>>>>>root `urls.py` in `my_project/my_project`, they are created 
>>>>>>>>>>in `my_project/config` 
>>>>>>>>>>- start the project with a custom User model app, `users` 
>>>>>>>>>>
>>>>>>>>>> Over the years, I've taught or tutored over 100 Djangonauts 
>>>>>>>>>> starting their first project. Having to distinguish between two 
>>>>>>>>>> directories 
>>>>>>>>>> with the same name is a constant pain point in the teaching process 
>>>>>>>>>> - "cd 
>>>>>>>>>> into my_project ... no, the other one!"
>>>>>>>>>>
>>>>>>>>>>- The `config` option seemed to be the consensus from this 
>>>>>>>>>>thread in the forum: Django New Project Structure/Name - 
>>>>>>>>>>Using Django - Django Forum (djangoproject.com) 
>>>>>>>>>>
>>>>>>>>>> <https://forum.djangoproject.com/t/django-new-project-structure-name/9987>
>>>>>>>>>>  
>>>>>>>>>>- Ticket: https://github.com/django/django/pull/15609 
>>>>>>>>>>
>>>>>>>>>> It is sometimes better to show rather than tell, so following our 
>>>>>>>>>> own documentation and including a custom User model with the initial 
>>>>>>>>>> project template reinforces the best practice that we explicitly 
>>>>>>>>>> point out 
>>>>>>>>>> in the document

Improvements to the startproject template

[Tim Allen]

Greetings, friends!

I've issued a PR that makes two changes to the `startproject` template:

   - instead of putting configuration files such 
   as `settings.py`, `wsgi.py`, and the 
   root `urls.py` in `my_project/my_project`, they are created 
   in `my_project/config`
   - start the project with a custom User model app, `users`

Over the years, I've taught or tutored over 100 Djangonauts starting their 
first project. Having to distinguish between two directories with the same 
name is a constant pain point in the teaching process - "cd into my_project 
... no, the other one!"


   - The `config` option seemed to be the consensus from this thread in the 
   forum: Django New Project Structure/Name - Using Django - Django Forum 
   (djangoproject.com) 
   
   - Ticket: https://github.com/django/django/pull/15609

It is sometimes better to show rather than tell, so following our own 
documentation and including a custom User model with the initial project 
template reinforces the best practice that we explicitly point out in the 
documentation.


   - Ticket:  #27909 (Use AUTH_USER_MODEL in startproject template) – 
   Django (djangoproject.com) 
   - Avoids ever having this come up 
   again: 
https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/

Here's a link to the PR: https://github.com/django/django/pull/15609

My apologies for not starting with a discussion first. I'm an infrequent 
contributor to the Django codebase!

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/33cb49d0-2469-47c0-920e-9501245c5a27n%40googlegroups.com.

Re: Revisiting MSSQL and Azure SQL Support in Django

[Tim Allen]

Thanks for the thoughtful replies, and the context - I'm mostly in 
agreement, and do hope that both Oracle and Microsoft step up as corporate 
sponsors (not to mention other companies that have been sold for eight or 
nine figures).

My hope is that we can give credit where credit is due, and acknowledge 
that Microsoft has made significant strides as an open-source partner. I 
want to encourage this behavior, as I've witnessed a change since Satya 
Nadella came on board. They have made life much easier for many of us in 
the Django community. My reply was primarily due to what I perceived as 
overly-harsh comments which don't seem to reflect the current-day Microsoft.

Take care,

Tim



On Sunday, April 3, 2022 at 2:23:35 PM UTC-4 f.apo...@gmail.com wrote:

> Hi Tim,
>
> On Friday, April 1, 2022 at 5:02:00 PM UTC+2 Tim Allen wrote:
>
>> The DB popularity index at db-engines.com has regularly listed the top 
>> four as Oracle, MySQL, Microsoft SQL Server, and PostgreSQL, in that order. 
>> I notice some comments in this thread about Microsoft being for-profit... 
>> well, what about Oracle? I don't see Oracle on the Support Django page 
>> either, yet two of their databases have support in core. MSSQL is the only 
>> one of the big-four RDBMS's without support in core Django. That seems to 
>> be a pretty big hole in Django's offering.
>>
>
> I understand that comparing to existing databases seems like to make an 
> argument for MSSQL but it is not that easy. First off, Django was released 
> way earlier than Oracle acquired MySQL -- I think it is understandable that 
> we do not simply drop support for a database just because Oracle buys it. 
> Postgres and MySQL (or now MariaDB) are both easily installable via every 
> Linux distribution and have been there since the beginning. Support for 
> Oracle itself (iirc) was added because the team at that point in time 
> thought it would enable Django to get access to areas where it hadn't 
> access before. Oracle itself has (imo) been proven to be quite a burden 
> over time and there had been discussion about removing it from core more 
> than once.
>
> Truth to be told, if the inclusion request for MSSQL gets serious we will 
> have to start a discussion about whether or not we simply nuke all database 
> backends (aside from sqlite maybe) from core. I'd be slightly in favor of 
> simply setting a policy for core that it should only include backends of 
> OSS databases. Why? Because it is way easier to install those on various 
> systems than their commercial alternatives (even if there are test licenses 
> and possibly free containers around there).
>  
>
>> They have put a lot of time and effort into this project, and I think 
>> they're well on their way to where they need to be for the long-term goal 
>> of being in core Django.
>
>
> I applaud to that, but I still do not understand why a well maintained 
> database backend needs to be inside core? And I am not just talking about 
> database backends here, we are saying no to pretty much every library 
> inclusion.
>  
>
>> A lot of the questions being asked of Microsoft in this thread just don't 
>> seem fair to me - we're not asking the same of Oracle, Redis Enterprise 
>> Software, or any of the other commercial products that Django has built-in 
>> support for. Why Microsoft and not the others?
>>
>
> We are asking Oracle but we are also not getting far, and simply kicking 
> it out is not something we do easily. As for Redis, as far as I am 
> concerned (and to the extend we support it) is open source.
>
> Cheers,
> Florian
>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/efd08dee-e86f-4fef-a39a-5fb89448fc48n%40googlegroups.com.

Re: Revisiting MSSQL and Azure SQL Support in Django

[Tim Allen]

Full disclosure: I've helped maintain SQL Server Django engine packages in 
the past, and was involved in getting the project started for the official 
Microsoft Django engine package.

First, thanks to Warren and the folks from Microsoft for creating this 
backend. There are a fair amount of users that need a Microsoft SQL Server 
backend, and for years we've been having to shuttle between 
barely-maintained engines, forks, and pip installs to commit hashes while 
waiting for merges. It is less than ideal. Several big supporters of Django 
(The Wharton School, RedHat Ansible, to name two) have been among those 
looking for a solid backend solution for years. Microsoft has provided us a 
vastly improved option to what we'd been saddled with for the past decade.

The DB popularity index at db-engines.com has regularly listed the top four 
as Oracle, MySQL, Microsoft SQL Server, and PostgreSQL, in that order. I 
notice some comments in this thread about Microsoft being for-profit... 
well, what about Oracle? I don't see Oracle on the Support Django page 
either, yet two of their databases have support in core. MSSQL is the only 
one of the big-four RDBMS's without support in core Django. That seems to 
be a pretty big hole in Django's offering.

That said, I completely agree that the backend still needs work, and a 
solid commitment from Microsoft before being brought into core Django. I 
want to make sure Microsoft knows that many in our community appreciate 
their efforts in taking the lead on this backend: support for SQL Server in 
the Django ecosystem is far better than it ever has been in my eight years 
of being a Djangonaut. They have put a lot of time and effort into this 
project, and I think they're well on their way to where they need to be for 
the long-term goal of being in core Django.

A lot of the questions being asked of Microsoft in this thread just don't 
seem fair to me - we're not asking the same of Oracle, Redis Enterprise 
Software, or any of the other commercial products that Django has built-in 
support for. Why Microsoft and not the others?

Warm regards,

Tim

On Friday, April 1, 2022 at 8:39:17 AM UTC-4 Salman Mohammadi wrote:

> Hi,
>
> IMO, Django is there to create value for *its* users.
>
> I'm not aware how MS Team reached this conclusion that merging their 
> incomplete package into Django core creates more value for Django users 
> than when it is a third-party package. Would you please tell me how?
>
> I have access to only two resources to calculate the popularity of 
> mssql-django package, one of them is the last Django Survey,
>
>
> https://www.djangoproject.com/weblog/2022/jan/03/django-developers-survey-2021-results/
>
> and the other one is Github Stars. None of them show any sign that MS 
> package is even semi-popular among Django users. 
>
> We have many popular packages that are residing outside of Django core and 
> living happily their lives.
>
> Probably MS wants to use this merge as a marketing point for their MSSQL, 
> a proprietary software.
>
> At the end I, as a total outsider with no direct connection of any kind 
> with Django project, have nothing against merging MS package into core the 
> same way that we have Oracle backend. But before that, there are some 
> questions that need to addressed:
>
> 1. How can MS package create more value for Django users by getting merged 
> into main branch?
>
> 2. According to your internal spying tools, how popular is your package?
>
> 3. How can you guarantee the long-term sustainability of your package?
>
> 4. What are the previous involvements of MS Package contributors in Django?
>
> 5. How does MS support Django Project for its long-term fundraising goals?
>
> 6. Is MS Team ready to follow Django Project deadlines? Especially release 
> dates and critical bugs. 
>
> 7. How does MS support Django Fellows in helping them triaging the 
> tickets, related to MS package. 
>
> Cheers, Salman
>
>
>
>
>
> Am 31. März 2022 18:30:06 MESZ schrieb Warren Chu :
>>
>> Hi All,
>>
>> There is increasing interest within Microsoft to have stronger ties 
>> between Microsoft SQL Server and Django. As you may be aware, Microsoft and 
>> their connectivity teams have been managing the 3rd party backend for 
>> "mssql-django" for over a year now at: 
>> https://github.com/microsoft/mssql-django
>>
>> Inclusion of SQL Server as a 1st party backend is viewed as a potential 
>> big milestone in that regard.
>>
>> @adamjohnson mentioned a year ago that ideally the community would like 
>> to see multiple years of ongoing Microsoft support before considering 
>> merging as a 1st party backend.
>>
>> We'd love to hear thoughts and feedback around the possibility of moving 
>> forward with a DEP enhancement proposal, with a commitment from Microsoft 
>> to providing continued dedicated support for the 1st party backend through 
>> the Django project itself (rather than the 3rd party repo).
>>
>> Cheers,
>> Team Microsoft
>>
>>

-- 
You 

Re: Revisiting Python support for after Django 3.2 LTS

[Tim Allen]

I often hear Ubuntu thrown around during these discussions, and it is my 
distro of choice for personal projects. But like many of us, I work at a 
RedHat / CentOS shop, and trying to maintain a current Python version is a 
much more difficult proposition. Unfortunately, IUS Community has stopped 
providing yum-installable versions of Python in an attempt to get EPEL to 
be more up to date, but that hasn't happened. To get a version of Python 
greater than 3.6 on RedHat / CentOS, AFAIK, you currently must build from 
source with altinstall.

I agree with Andrew's statement that we should consider each version. I can 
see dropping Python 3.5 support - it would allow us to use a feature like 
f-strings, which improves readability and speed throughout the codebase, 
and is ubiquitous in Python. But what does dropping Python 3.6 support 
really achieve? Do we need data classes?

I realize there is a need to move forward, especially for wonderful things 
like better async support. I just ask that we also consider those of us 
using Django in corporate or academic settings where the pace of upgrading 
Python is a bit more glacial.

On Thursday, November 19, 2020 at 11:51:29 AM UTC-5 Andrew Godwin wrote:

> I agree we should not be quite so beholden to our existing Python version 
> policy - that was mostly to get us out of the early 3.x era. Now things are 
> more stable, I'd support a policy that is much more like "any stable 
> version of Python currently out there and supported".
>
> Andrew
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/83fc7a73-aa7d-4390-805f-c50c496175f8n%40googlegroups.com.

Re: What the purpose of having function that is not working correctly?

[Tim Allen]

I've seen recommendations to use this during conference talks by people 
with a fairly deep knowledge of the ORM as recently as 2019, so I do 
believe it can be made more blatantly clear in its purpose. We took a stab 
at improving it during DjangoCon 2019. Consensus was that:

(a) when the underlying DB driver provides a method of constructing the 
query, a la PostgreSQL's `mogrify`, we can use it;
(b) when the underlying DB driver does NOT provide a method, we can make it 
obvious not to use it for more than debugging. IIRC, Tim Graham suggested 
we construct the string to be something like, """SQL: SELECT ... FROM ... 
WHERE x = ? AND y = ? PARAMS: ("this", "that")""" to provide the relevant 
information, but make it very obvious you can't copy pasta it into a SQL 
command line tool.

Here's the PR we were working on, which also contains some good discussion 
and background in addition to Claude's PR: 
https://github.com/django/django/pull/10568

...but ultimately, we decided Claude's approach linked by Mariusz above was 
better. I'd love to see this cross the finish line one of these days; my 
burning use case was eventually solved when `queryset.explain()` was 
introduced in Django 2.1.

On Friday, September 11, 2020 at 10:16:22 AM UTC-4 fran.h...@gmail.com 
wrote:

> Just my $.02, literally yesterday I saw a str(queryset.query) used to 
> construct a raw SQL query. It of course suffers from the worst kind of SQL 
> injection as well.
>
> +1 to make it obvious, somehow, that kittens die every time it is used for 
> a real query.
>
>
>
> On 11 Sep 2020, at 15:58, Alexander Lyabah  wrote:
>
> I'm sorry. Now things sound even more confusing for me.
>
>
> From one side you've said that "No, this function is never working in a 
> useful way." (but my example from the post shows, how it works in the 
> beginning and then stops working for datatime, which means it was pretty 
> much useful for some very common cases)
>
> From another side, you have accepted tickets, to make this function works 
> in a useful way.
>
> So it very looks like you've made a function, that returns something, that 
> very looks like SQL, but shouldn't be used as SQL, it is just for debug, 
> and you have a bunch of tickets to make SQL-like debug text to be working 
> as real SQL.
>
> So, my humble suggestion here is very simple. If you don't want something 
> to be used in an appropriate way, don't make it looks like it can be used 
> this way. 
>
>  
>
> On Thursday, September 10, 2020 at 1:40:33 PM UTC+3 f.apo...@gmail.com 
> wrote:
>
>> On Thursday, September 10, 2020 at 11:16:56 AM UTC+2 Alexander Lyabah 
>> wrote:
>>
>>> The problem with the function is that it is actually working, but not 
>>> always, and because of that, other people are suggesting it on 
>>> StackOverflow, using it in prod, and may, eventually catch weird 
>>> exceptions, which leads to a bad experience with Django in general.
>>>
>>
>> No, this function is never working in a useful way. It does client side 
>> interpolation of query params which should be done by the drivers instead, 
>> even when it works it is potentially dangerous. The actual problem is that 
>> people on StackOverflow recommend to use it. FWIW Since it is solely a 
>> debugging aid I'd actually break any usage of it by adding "--" to the 
>> start of it (or similar)
>>  
>>
> -- 
>
> 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/487cadce-51db-418f-aca4-ebe14aa16bb9n%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/81ed71d5-f83e-4e36-8cb9-f718dd33515en%40googlegroups.com.

Re: command for stopping server

[Tim Allen]

The advice here is solid, but to answer the initial query... i created a 
one liner to kill any runservers from my current user, as they can get lost 
in my sea of terminals. This may help:

alias kill-runserver="ps -eaf | grep 'manage.py runserver' | 
grep "'$USER'" | grep -v grep | awk '{print "'$2'"}' | xargs kill -9"

Good luck!

On Monday, September 7, 2020 at 9:37:50 AM UTC-4 tond...@gmail.com wrote:

> Hello there,
>
> This question on StackOverflow is a workaround for stopping the server
>
> https://stackoverflow.com/questions/27066366/django-development-server-how-to-stop-it-when-it-run-in-background
>
> Basically I would like to run the server and stop it by a program, it is 
> hard, when the default way is literally "pressing ctrl+C",
> killing the process is different on different OS'es.
> When searching the web (StackOverflow) users replies to individual answers 
> were "This worked for me." or "This didn't work for me.",
> this showcases that different conditions make it hard to get to actually 
> stopping the server.
>
> A unified solution would be very nice. If we want to keep "python 
> manage.py runserver" together with "press ctrl+C to quit",
> then I would suggest a new command, let's call it "startserver", that 
> would be non-blocking, running subprocess, or something,
> once the user is done he simply calls "stopserver" to stop it.
> "startserver" vs "runserver" might be similar for some, suggest different 
> command name if you like.
>
> It is only my suggestion, I don't care if it will be more complicated as 
> long as it will "just work" on all OS'es and will be clear to use.
>
> Thanks for your time and consideration
> Antonín Drdácký
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5712fd9d-2555-45f2-ad7c-3e4d05b65660n%40googlegroups.com.

Re: Rename request.GET and POST, and lowercase COOKIES, FILES, and META

[Tim Allen]

I'm tentatively +1 on this change... but...

While it may be a straightforward operation to do a case sensitive search 
and replace in most code bases, it is not trivial to do so on the rest of 
the web. If we're going to do this, we must realize that this will 
invalidate thousands of examples, tutorials, and answers in communities 
such as Stack Overflow, the Django Forum, the Django Girls Tutorial, and 
the archive of this Google Group. It has been a few years now since Django 
2.0, and I still find myself frequently helping junior developers amend 
their PRs to move to `path` and `re_path` instead of `url`, which they 
copypasta'd from somewhere. I was also for that change, but as a community, 
we need to be cognizant of the fact that as its ambassadors, we are going 
to have a fair amount of work to do to properly spread the word about a 
change like this.

There are many possible responses to why that shouldn't be happening in a 
perfect world, unfortunately, we have to exist in this reality! (I'm hard 
at work at the unreality PR for Django 5.0.)

So let's make sure we consider the full impact of this change before we do 
it. I have some pet peeves about Django naming choices, but where do we 
stop? Two examples:

* createsuperuser -> create_super_user, queryset -> query_set,  for 
readability and to be more Pythonic
* HttpResponse should be HTTPResponse, like DjangoJSONEncoder, for example. 
(From PEP-8: "Note: When using acronyms in CapWords, capitalize all the 
letters of the acronym. Thus HTTPServerError is better than 
HttpServerError.")

Something to consider for the future about when the churn is worth it, and 
when it isn't. Thanks, y'all.

>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5022af59-4280-4dca-a33e-d7ec79bc131b%40googlegroups.com.

Re: Adding support for SQL Server

[Tim Allen]

I don't think GitHub stars are a fair assessment; the backend that was most 
widely used for years has over 300: 
https://github.com/michiya/django-pyodbc-azure

But that doesn't really tell much of the story, because the Django backends 
for SQL Server have been so fragmented over the years. Since I started with 
Django in 2015, I've used five different backends for SQL Server support. 
That is the problem: SQL Server is the only one of the "big four" RDBMS's 
without support from core Django (https://db-engines.com/en/ranking). If a 
newcomer using SQL Server tries to find what Django database backend to 
use, they're going to have a heck of a time trying to figure it out on 
Google. There are also fairly large companies that use Django for products 
that can not currently offer support to their corporate clients who require 
SQL Server, because there isn't a reliable commitment to support it.

On the flip side of the coin, Oracle support is the closest analog we have 
to SQL Server support, as they are both paid products from very large 
corporate entities. Oracle is largely supported because the people who need 
it are committed to making it happen in core. As a guestimate, supporting 
SQL Server in core Django would require 6-8 weeks of a properly skilled FTE 
to bring the backend into feature parity with the existing backends, and 
about 2 weeks of an FTE per Django release cycle. Once a group of people, 
or a corporate entity, steps up to commit these resources, it is much more 
likely to happen.

To wildly speculate on Martynas Puronas's question, while there are 
currently backends in core, there are advantages to having the backend as a 
separate package under the Django umbrella. This is similar to why pytz is 
a separate from Python itself. It would allow for separate release cadences 
in line with the underlying database's release schedule. While it certainly 
isn't my decision to make, I could see Django moving in this direction for 
other database backends in the future.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d1954c91-c2a0-4cd1-9b4f-d2baaf575e1b%40googlegroups.com.

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

Hi Sean, just an update from what I know.

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

On Monday, December 2, 2019 at 11:03:56 AM UTC-5, Sean Martz wrote:
>
> Hello,
>
> It seems like this issue has lost momentum. Is this still something that's 
> on anyones radar? It looks like django-pyodbc-azure is not actively 
> maintained anymore (it looks like Michaya has taken a hiatus from GitHub). 
> It also looks like there's a small community potentially popping up that's 
> interested in first class MSSQL Server support for Django. (
> https://github.com/FlipperPA/django-mssql-backend). Is Microsoft still 
> interested in committing resources to this goal? In my situation, it would 
> be a lot easier to sell stakeholders and decision makers on Django if it 
> had first class support for MSSQL Server.
>
> For what it's worth, Django-pyodbc-azure is still working well.
>
> Cheers,
> Sean
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3683f606-ad18-4935-85c8-8ca3ea18fecc%40googlegroups.com.

Re: Individial Member Nomination for the DSF: Louise Grandjonc

[Tim Allen]

My apologies friends, this was intended for the DSF members mailing list. I 
had a momentary brain freeze!

On Tuesday, September 17, 2019 at 5:15:23 PM UTC-4, Tim Allen wrote:
>
> Good afternoon friends, happy "four days until DjangoCon US!"
>
> I'd like to nominate Louise Grandjonc to the Django Software Foundation. 
> Louise has given excellent talks on scaling multi-tentant apps using 
> Django's ORM and PostgreSQL, and will be presenting at DjangoCon US this 
> year. She's written numerous blog posts that have been extremely helpful to 
> me in understanding the inner workings of PostgreSQL, and is interested in 
> getting more involved with Django.
>
> She's also quite an artist, as you can see is some of her hand-dawn 
> slides: 
> https://speakerdeck.com/citusdata/scaling-multi-tenant-applications-using-the-django-orm-and-postgres-pycaribbean-2019-louise-grandjonc
>
> Can I get some plus ones? :)
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f13e010a-03e6-4674-8db0-1a2f71e67aca%40googlegroups.com.

Individial Member Nomination for the DSF: Louise Grandjonc

[Tim Allen]

Good afternoon friends, happy "four days until DjangoCon US!"

I'd like to nominate Louise Grandjonc to the Django Software Foundation. 
Louise has given excellent talks on scaling multi-tentant apps using 
Django's ORM and PostgreSQL, and will be presenting at DjangoCon US this 
year. She's written numerous blog posts that have been extremely helpful to 
me in understanding the inner workings of PostgreSQL, and is interested in 
getting more involved with Django.

She's also quite an artist, as you can see is some of her hand-dawn 
slides: 
https://speakerdeck.com/citusdata/scaling-multi-tenant-applications-using-the-django-orm-and-postgres-pycaribbean-2019-louise-grandjonc

Can I get some plus ones? :)

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c5331faf-ea1a-479a-a26c-4e084b7d42bb%40googlegroups.com.

Re: Proposal to format Django using black

[Tim Allen]

Another plus one for Black, without getting too into the weeds. I think the 
time is will save likely outweigh the valid concerns posted here. I've used 
Black extensively on several projects, and much like f-strings, the last 
Pink Floyd album, and broccoli, have found I really like something I didn't 
think I would.

I've gone through the churn of style edits each time I've made a PR to 
Django, despite using flake8. Having an automated tool to avoid that 
back-and-forth time would be a big help. It would also help reduce feelings 
of impostor syndrome; I know I've kicked myself for making basic formatting 
mistakes. Submitting to a project like Django can be intimidating, and this 
would remove some of the intimidation factor. I like to ask with every 
major change, "What does it mean for the newcomer?" Much like the new 2.0 
URL routing syntax, I think this is  a slam-dunk.

While I prefer longer line lengths, I agree we should just stick with 
Black's defaults. Their commentary on the choice of 88 characters is 
compelling: it saves quite a bit of space over PEP-8's 79, but stays 
readable for the greater majority of people. Keeping the code base 
accessible to as many as possible is a big plus. I also find that with 88 
character limits, I can keep three files open on a 16x9 screen in an 
editor, which is a nice editor workspace while working on Django (models 
file, views file, template). While Black may change in the future, I doubt 
the changes would be so large as to cause us to need another "huge commit 
and merge."

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/3b3f2605-f10e-4262-8547-c854c5cad644%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Tim Allen]

I'm in the camp of having a flexible policy that allows us to have 
discussions that examine the current state of the Django and Python 
ecosystems. This allows us to make informed decisions.

As several folks have mentioned before, 3.6 was a more momentous release 
than most versions of Python. Since moving to it, features that I didn't 
think I'd like initially have grown into ones I couldn't imagine working 
without, such as f-strings. Easier to read, less cognitive load of "fill in 
the blank" replacement, more beautiful code, straightforward to explain 
newcomers, and faster?! That's just one example of a huge win that might 
lower the bar to entry of contribution to Django. More efficient memory use 
in dicts and type annotations are other big wins.

I typically might lean to the side of supporting versions for longer, but 
in this case, I'm firmly in the 3.6 camp because of the nature of the 
release.

I also thought I'd mention that within my organization, the version of 
Python that Django supports is a driver that I appreciate. While some 
groups keep up with the latest Python versions, other groups aren't as 
good, only upgrading when necessary. I won't get into the politics of the 
developers who want newer versions versus sysadmins who don't want to 
change, but I've appreciated Django helping move things forward.

-- 
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/d108f73f-72cc-4180-a26b-95920413adcf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A faster paginator for django

[Tim Allen]

On Friday, December 21, 2018 at 10:18:04 AM UTC-5, Cristiano Coelho wrote:
>
> Let's not forget how the various *count *calls starts to kill your 
> database when you get over 1 million rows (postgres at least).
>
> So far the only options I have found with postgres are:
> - Estimate count for non filtered queries: SELECT reltuples::BIGINT FROM 
> pg_class WHERE relname = '%s';
> - If queries are filtered, replace it with a subquery that will first 
> limit the results to a reasonable number (such as 1k), this is silly, and 
> won't allow you to go through all results but at least the count call won't 
> kill your database. This is only useful if the filtered query returns over 
> one million rows as well.
>

I had this problem with very large tables of data being presented as 
endpoints through DRF. For filtered queries estimate, we parse the EXPLAIN 
syntax to get an approximate rowcount, which handles filtered queries. It 
is by no means perfect, but allows us to have next / previous pagination 
while using the EXPLAIN approximate count for an estimated total. We then 
keep showing NEXT until there's a page with no results. More frequent 
vacuums of PostgreSQL are another option for improving accurance of the 
estimate count you mention. We subclassed DRF's limit/offset pagination and 
overrode the count() method to accomplish this. It might be an option to 
consider for Django pagination as well, especially with EXPLAIN now being 
available through the ORM in 
2.1: https://docs.djangoproject.com/en/2.1/ref/models/querysets/#explain

-- 
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/fb3fd1b6-75ed-454d-85c3-ba0672e5368f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending django.contrib.auth.models Group name to be 191 character max_length

[Tim Allen]

I've amended the PR to be 150 characters rather than 191.

Thanks for doing the digging which explains why I had 191 characters stuck 
in my head. I'm in the "as long as possible to cover the most possible 
cases" camp, but 150 would seem to hit the 99.9%, so let's call it a 
win! 


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/a19a7877-70e5-4169-91c4-542c75008d2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Extending django.contrib.auth.models Group name to be 191 character max_length

[Tim Allen]

Greetings,

Over the past few releases, several CharFields in django.contrib.auth have 
been increased to a max_length of 191: username, first_name, and last_name 
immediately 
come to mind.

See: 
https://groups.google.com/forum/#!msg/django-developers/h98-oEi7z7g/xzjtFMf1BwAJ

I've issued a PR to extend Group.name to the same length 
here: https://github.com/django/django/pull/10627 The original ticket this 
is addressing was from a colleague who was bumping into the limit when 
syncing groups to Django from 
LDAP: https://code.djangoproject.com/ticket/29939

The 191 character limit was chosen to support MySQL index limits.

Can anyone think of a reason not to change Group.name to be max_length=191 
as we have with the other fields?

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/a9304881-1d2c-4bc7-84aa-cd9715f443ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Tim Allen]

Since `django-admin startproject my_project` is created on the fly from 
templates, couldn't we dynamically create the `manage.py` executable based 
on some system introspection and an agreed upon priority?

Regards,

Tim

On Tuesday, April 10, 2018 at 4:28:12 AM UTC-4, Adam Johnson wrote:
>
> Oh yeah, duh, my bad :)
>
> On 9 April 2018 at 23:35, Collin Anderson  > wrote:
>
>> I'm thinking something like #!/usr/bin/env 
>> {{ os.path.basename(sys.executable) }} when running startproject. (Though 
>> on windows I that would be #!/usr/bin/env python.exe - not sure if that 
>> would work or not)
>>
>> On Mon, Apr 9, 2018 at 3:58 PM, Adam Johnson > > wrote:
>>
>>> (Or would it work to use os.path.basename(sys.executable) ?)
>>>
>>>
>>> The shebang is interpreted by the OS so this is before python even 
>>> starts :)
>>>
>>

-- 
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/171caf56-a3cb-497d-9ebf-0a1ca61a31eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

Hi Kunal, welcome to the Django community! django-pyodbc-azure is the best 
maintained SQL Server engine I've found, and it typically gets updated a 
little more quickly than this. However, Michaya who maintains the package 
has been extremely busy lately, and said it will take him a few more weeks 
to get it done. If you're starting a new project, could you develop on 
SQLite for now and then swap in django-pyodbc-azure when it is ready?

Regards,

Tim

On Thursday, January 18, 2018 at 8:39:42 AM UTC-5, 
kunal...@williamoneilindia.com wrote:
>
> Hi,
>
> I am new to Django, but planning to use Django 2.0 for my newest project. 
> I am using MSSQL db and hence facing issues with it.
>
> Anyone working on getting an MSSQL backend that works with Django 2.0? 
> (Couldn't find one that's up to date including django-pyodbc-azure).
>
>>
>>>

-- 
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/da8052d9-9d3e-4ffd-8432-2b0970226df4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pretty formated JSON editor for django.contrib.postgres.fields.JSONField in django admin.

[Tim Allen]

This would certainly make a good package, but I'm not sure it belongs in 
core Django, as it would likely introduce dependencies for everyone.

I've done something similar for the Wagtail CMS on Django using the PrismJS 
library: https://github.com/FlipperPA/wagtailcodeblock A similar package 
only using JSON could be built for the Django admin for those who want it.

-- 
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/63cc0876-cc4f-443d-848a-594b20b83d3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Willing to contribute to Django

[Tim Allen]

>From there, you're one click away from the tickets. Here's a link to the 
"Easy Pickings" currently open:

https://code.djangoproject.com/query?easy=1=id=summary=status=owner=type=component=version=1=id

-- 
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/dd037d7b-e20b-49de-8abb-517ce8e16b20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PostgreSQL Partial Indexes package

[Tim Allen]

I would love to see partial indexes supported. Great work! As far as 
databases with Django support:

- PostgreSQL supports partial indexes
- SQLite supports partial indexes
- SQL Server supports them, called "filtered indexes"
- Oracle: Sort of supports 
them: https://blog.jooq.org/2017/01/18/how-to-emulate-partial-indexes-in-oracle/
- MySQL/Maria/Drizzle: no support, AFAIK.

Would we want to build partial indexes in for all databases, with the 
caveat that they would be ignored on MySQL and perhaps Oracle? In those 
cases, would be default to a full index?

Regards,

Tim

On Saturday, October 7, 2017 at 4:56:00 AM UTC-4, Mattias Linnap wrote:
>
> Hi django-developers,
>
> I have written a package that implements PostgreSQL and SQLite partial 
> indexes on top of the new class-based indexes: 
> https://github.com/mattiaslinnap/django-partial-index
> The most common use case is partial unique constraints, but I have a few 
> projects where non-unique partial indexes have turned out useful as well.
>
> I have a few questions on how to continue with this:
>
> 1. Right now the "where condition" expression is provided as a string, and 
> has to be different for PostgreSQL and SQLite in some common cases (for 
> example boolean literals). Is there a good abstraction for SQL expressions 
> somewhere in Django internals that I could use instead, something similar 
> to Q-expressions perhaps? In particular, to add validate_unique() support 
> to ModelForms, I would need to be able to extract all fields that are 
> mentioned in the where condition.
> 2. I've seen mentions of a "check constraints" support being in 
> development (https://github.com/django/django/pull/7615). Will that 
> include partial unique constraints, or is just for the per-column checks?
> 3. If separate, then it would be nice to one day get partial indexes 
> merged into the contrib.postgres package. Do you have any suggestions on 
> what needs to happen before that - more test coverage, more contributors, 
> more users, or similar?
>
> Best,
>
> Mattias
>

-- 
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/df13ff66-8033-4f91-b49a-081bfa28db00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Refactoring the autoreloader

[Tim Allen]

If we need some dogfooding with real-world candidates, I'd be happy to 
provide some. We have a project which currently takes ~20 minutes to start 
up (automated data models created by introspecting a database) that might 
be a good edge-case candidate.

-- 
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/33edd13f-7867-4a0c-b834-fbee47e2f5b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: drop support for MySQL 5.5 in Django 2.0?

[Tim Allen]

SQL Server microsecond support (DATETIME2) was first introduced in SQL 
Server 2008. I can't speak on behalf of Michaya or those maintaining other 
SQL Server backends, but in our use cases dropping support for 2005 by 
switching from DATETIME to DATETIME2 exclusively would make sense. That 
said, we are slowly but surely becoming a PostgreSQL shop, so someone who 
relies on SQL Server more heavily than us may have further input. The 
standalone DATE column was also introduced in SQL Server 2008.

I've started a thread here to discuss with 
Michaya: https://github.com/michiya/django-pyodbc-azure/issues/109

On Wednesday, August 30, 2017 at 3:49:32 PM UTC-4, Tim Graham wrote:
>
> I guess a SQL Server expert will need to interpret 
> https://blogs.msdn.microsoft.com/sqlnativeclient/2008/02/27/microsoft-sql-server-native-client-and-microsoft-sql-server-2008-native-client/
>  
> and say exactly which SQL Server versions require the legacy datetime 
> handling. I see django-pyodbc-azure still supports Microsoft SQL Server 
> 2005 (end of extended support was April 2016) and SQL Server 2008/2008R2 
> (end of mainstream support 2014, end of extended support July 2019). If 
> those are the only SQL Server versions that don't have microsecond support, 
> django-pyodbc-azure might consider dropping support for them -- doubtful if 
> those users require the latest version of Django, I'd guess.
>
> I'm not strictly opposed to keeping the supports_microsecond_precision 
> feature around if it's helpful for that backend, but we'll need 
> contributions from django-pyodbc-azure maintainers to keep it updated 
> (mainly with respect to using the feature to skip or change behavior in 
> tests).
>
> On Sunday, August 27, 2017 at 6:51:40 PM UTC-4, Tim Allen wrote:
>>
>> AFAIK, the *supports_microsecond_precision* feature is still needed by 
>> *django-pyodbc-azure*, because of SQL Server's, ahem, creative datetime 
>> fields.
>>
>> See: 
>> https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/operations.py#L474
>>
>> There is a fair amount of logic needed (based off of the FreeTDS version 
>> and SQL Server version) necessary as well to determine whether to use SQL 
>> Server's *datetime* or *datetime2:*
>>
>>
>> https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L80
>>
>> https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L461
>>
>> It may be possible to modify *django-pyodbc-azure* to work another way, 
>> but for that I would defer to Michaya. I haven't used any of the other 
>> pyodbc forks in years, as *django-pyodbc-azure* is very well maintained 
>> and supports both SQL Server and Azure.
>>
>> On Saturday, August 26, 2017 at 11:09:42 AM UTC-4, Tim Graham wrote:
>>>
>>> MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a 
>>> particular database version in the Django release prior to the end-of-life 
>>> date [0], so that would mean dropping support in Django 2.1 (released 
>>> August 2018). We don't have MySQL 5.5 testing in our continuous integration 
>>> servers and in local testing, I noticed some GIS test failures with MySQL 
>>> 5.5. Before investigating them, I thought I'd ask to see if there might be 
>>> consensus to drop support for MySQL 5.5 in Django 2.0 instead of 2.1. I'd 
>>> guess anyone using MySQL 5.5 users would stick with Django 1.11 LTS or 
>>> older.
>>>
>>> https://github.com/django/django/pull/8980 shows the cleanups for 
>>> removal of MySQL 5.5 support. Also, MySQL 5.5 is the last usage among the 
>>> built-in database backends for the supports_microsecond_precision 
>>> database feature so there's a chance that could be removed also, though I 
>>> found usage of it in django_pyodbc [1].
>>>
>>> [0] https://code.djangoproject.com/wiki/SupportedDatabaseVersions -- though 
>>> we've made some exceptions like dropping support earlier for Oracle 11, 
>>> https://groups.google.com/forum/#!topic/django-developers/IawbBWzPXaA/discussion
>>> [1] https://github.com/lionheart/django-pyodbc/issues/87
>>>
>>

-- 
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/1c688f05-1a12-4f59-a77f-34cd36613c1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: drop support for MySQL 5.5 in Django 2.0?

[Tim Allen]

AFAIK, the *supports_microsecond_precision* feature is still needed by 
*django-pyodbc-azure*, because of SQL Server's, ahem, creative datetime 
fields.

See: 
https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/operations.py#L474

There is a fair amount of logic needed (based off of the FreeTDS version 
and SQL Server version) necessary as well to determine whether to use SQL 
Server's *datetime* or *datetime2:*

https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L80
https://github.com/michiya/django-pyodbc-azure/blob/4df37f3ec40abaf1aca608e1922a93073db8f144/sql_server/pyodbc/base.py#L461

It may be possible to modify *django-pyodbc-azure* to work another way, but 
for that I would defer to Michaya. I haven't used any of the other pyodbc 
forks in years, as *django-pyodbc-azure* is very well maintained and 
supports both SQL Server and Azure.

On Saturday, August 26, 2017 at 11:09:42 AM UTC-4, Tim Graham wrote:
>
> MySQL 5.5 is end-of-life in December 2018. Usually we drop support for a 
> particular database version in the Django release prior to the end-of-life 
> date [0], so that would mean dropping support in Django 2.1 (released 
> August 2018). We don't have MySQL 5.5 testing in our continuous integration 
> servers and in local testing, I noticed some GIS test failures with MySQL 
> 5.5. Before investigating them, I thought I'd ask to see if there might be 
> consensus to drop support for MySQL 5.5 in Django 2.0 instead of 2.1. I'd 
> guess anyone using MySQL 5.5 users would stick with Django 1.11 LTS or 
> older.
>
> https://github.com/django/django/pull/8980 shows the cleanups for removal 
> of MySQL 5.5 support. Also, MySQL 5.5 is the last usage among the built-in 
> database backends for the supports_microsecond_precision database feature 
> so there's a chance that could be removed also, though I found usage of it 
> in django_pyodbc [1].
>
> [0] https://code.djangoproject.com/wiki/SupportedDatabaseVersions -- though 
> we've made some exceptions like dropping support earlier for Oracle 11, 
> https://groups.google.com/forum/#!topic/django-developers/IawbBWzPXaA/discussion
> [1] https://github.com/lionheart/django-pyodbc/issues/87
>

-- 
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/6a97bf2b-3a90-4f68-ba34-86b39a649d64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrate dj-database-url into Django

[Tim Allen]

I've recently been introduced to `django-environ`, a similar library that 
has additional features to DB connect URLs that we may want to consider: 
https://github.com/joke2k/django-environ

It has the same issue with third party DB engines; for example, I recently 
issued a PR to include `pyodbc` as an option. It has some nice newcomer 
friendly features, such as a cleaner way of determining BASE_URL / 
SITE_ROOT. Have a look at the URL for a good "before" and "after" settings 
file example.

Having full support for .env files would make Django projects easier to 
bring in line with 12-factor.

Regards,

Tim

On Saturday, May 27, 2017 at 3:52:23 PM UTC-4, Tom Forbes wrote:
>
> Edit: DJANGO_SETTINGS_MODULE isn't relative, it will import any arbitrary 
> module you give it. If we accept that then I think we are accepting the 
> risk of imports via an attacker controlling environment variables whilst 
> Django starts up?
>
> On Sat, May 27, 2017 at 8:49 PM, Tom Forbes  > wrote:
>
>> > I'm wary of possible security ramifications: if we do this, changing a 
>> configuration value will import an arbitrary module, which could make it 
>> easier to run arbitrary code in some scenarios. I don't have a clear threat 
>> model in mind here, though.
>>
>> Good point, it's not wise to enable this even without a clear threat 
>> model. Django does import the settings based on an environment variable, 
>> but it's relative and if you can use that to do anything nasty then you're 
>> most likely already through the airtight hatch (so to speak). However 
>> importing potentially global modules could be bad news.
>>
>> Ignoring it is always an option, but could we not specify that the third 
>> party database provider has to be in the `INSTALLED_APPS`? That could 
>> provide some form of whitelisting so not any old module is imported. Not 
>> sure about any issues that may arise from this though.
>>
>> > One possibility would be to use entrypoints in setuptools, this way 3rd 
>> party backends could specify a name which then has a fixed & verified 
>> import path.
>>
>> This seems like it could get complex, and be quite unlike anything else 
>> in Django.
>>
>> Perhaps just supporting this for first-party database backends is easiest?
>>
>> On Thu, May 25, 2017 at 8:46 AM, Aymeric Augustin <
>> aymeric@polytechnique.org > wrote:
>>
>>> Hello,
>>>
>>> I'm wondering what the exact definition of the URL format is. Is it 
>>> specified somewhere? Or is it just:
>>>
>>> [engine]://[username]:[password]@[host]:[port]/[name]
>>>
>>> where we create arbitrary [engine] values in an ad-hoc fashion?
>>>
>>> On 24 May 2017, at 21:21, Tom Forbes  
>>> wrote:
>>>
>>> My two cents: connection strings/database URI's are a feature I've 
>>> sorely missed in Django.
>>>
>>> Built-in functionality to convert environment variables like 
>>> DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant 
>>> DATABASE setting would make some deployment situations a lot simpler. 
>>> Currently, unless you use dj-database-uri you have to define a bunch of 
>>> ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary 
>>> together yourself.
>>>
>>>
>>> Fully agreed. While relatively minor, it's an annoyance.
>>>
>>> How does this library complex keys like OPTIONS, TEST or DEPENDENCIES?
>>>
>>>
>>> I don't think it's reasonable to cram them in a URL.
>>>
>>> dj-database-url allows passing options as extra keyword arguments. Other 
>>> values should be explicitly added in the settings module, by updating the 
>>> dict generated from the URL.
>>>
>>> To help support third part backends: perhaps the scheme portion of the 
>>> URI could be either a relative import from django.db.backends or an 
>>> absolute import to a third party library? It seems URI schemes can have 
>>> dots and underscores in them, so they can be python package paths.
>>>
>>> I.e sqlite3://xyz would resolve go django.db.backends.sqlite3, but 
>>> sqlserver_ado://xyz would resolve to the third party django-mssql engine 
>>> via an absolute import.
>>>
>>>
>>> I'm wary of possible security ramifications: if we do this, changing a 
>>> configuration value will import an arbitrary module, which could make it 
>>> easier to run arbitrary code in some scenarios. I don't have a clear threat 
>>> model in mind here, though.
>>>
>>> I'd rather specify the database engine explicitly when calling 
>>> dj-database-url if it's a third-party engine. There's an open question 
>>> about what to do with the [engine] part of the URL in that case. Ignoring 
>>> it entirely is the easiest.
>>>
>>> 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 

Re: A New Design for the "Congratulations!" Page

[Tim Allen]

Your point on design by committee is spot-on; I think that's the direction 
we'll head in. Thanks for the kind words, and I've noted the issues on the 
smaller height and smaller screen issues. It is much apprecaited!

Regards,

Tim

On Tuesday, April 18, 2017 at 1:30:23 PM UTC-4, Aymeric Augustin wrote:
>
> Given the well-documented success rate of design by committee, including 
> our experience redesigning djangoproject.com, there's a risk that an 
> inconclusive discussion on this mailing list will prevent your proposal 
> from moving forwards.
>
> Perhaps a good way to avoid that would be to form a small team (two or 
> three people, including yourself and at least one committer) to evaluate 
> the feedback and reach consensus in a smaller group. (I'm happy to help 
> with the technical aspects e.g. how to load fonts.)
>
> For what it's worth, I noticed a couple layout glitches in the current 
> proposal, but nothing major:
> -  can overlap  and  at small heights e.g. with 
> developer tools open at the bottom
> - links look bad at 320px wide — try the "iPhone 5" setting in Chrome's 
> responsive view
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 18 Apr 2017, at 17:44, Tim Allen <t...@peregrinesalon.com > 
> wrote:
>
> I've had the privilege of introducing Django to many people over the past 
> several years. A recurring theme I have noticed is that once a new Django 
> developer reaches the "It Worked!" page, the inevitable next question is, 
> "now what?"
>
> It struck me that this page is valuable real estate for the newcomer. 
> Since my eye for design is practically non-existent, I worked with a 
> talented colleague and we came up with an idea to replace the "It Worked!" 
> page. Here is a link:
>
> https://chadwhitman.github.io/congrats/django/
>
> Some of the goals we wanted to achieve:
>
>- Provide a friendly design using the same themes as the Django 
>Project website.
>- Ensure the developer is using the current version of Django. Many 
>tutorials found through Google are for older versions of Django.
>- Provide links to the current versions of the documentation, 
>introductory polling tutorial, and community.
>- Include the release notes for the current version of Django.
>- Focus on the new Django developer, as many seasoned Django 
>developers will using other methods for starting projects.
>
>
> While it is doubtful that many would see this screen on a small device, it 
> is fully responsive as well. It is self-contained, with minified CSS and 
> SVG icons, and a total size of 20k, so it shouldn't provide much bloat at 
> all.
>
> We're looking for feedback, and if the community thinks it is an 
> improvement, we'll be happy to work on a pull request. A big hat tip to my 
> colleague Chad Whitman for his design talents.
>
> 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 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/CACrTqc1%3Du9oG9At%3DY-SxavYtvwTb6qN5dSAUDJL0AkxJrKvQQQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CACrTqc1%3Du9oG9At%3DY-SxavYtvwTb6qN5dSAUDJL0AkxJrKvQQQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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/3817793d-ec2e-4f8f-863b-1f17bce8220d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A New Design for the "Congratulations!" Page

[Tim Allen]

Thanks for the kind words. To answer your questions:

- My colleague Chad did the rocket animation. We'll both do git signed 
commits on any pull request and add ourselves to authors.
- It is also my hope to automagically create version friendly links, so we 
don't see a commit on each Django release.
- Good catch on the CSS. We're tracking these issues.

On Tuesday, April 18, 2017 at 12:15:10 PM UTC-4, Collin Anderson wrote:
>
> Does a license need to be included for the rocket animation, or is that 
> your own work?
> I hope the links could be auto-generated so they don't need to be 
> hand-updated with every version.
> I think the unused css should be removed. We're not 
> using button,input,optgroup,select,textarea, etc.
>
>
>
> On Tue, Apr 18, 2017 at 12:03 PM, Tim Allen <fli...@peregrinesalon.com 
> > wrote:
>
>> Switching to another font is certainly an option. Is the issue with 
>> Google Fonts the Apache license versus the Django BSD license?
>>
>> -- 
>> 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/c635d1e2-45e5-4b31-8ae2-f6acb00f943f%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-developers/c635d1e2-45e5-4b31-8ae2-f6acb00f943f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/6f446d97-29a3-4c40-88c6-94e11919aea3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A New Design for the "Congratulations!" Page

[Tim Allen]

Switching to another font is certainly an option. Is the issue with Google 
Fonts the Apache license versus the Django BSD license?

-- 
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/c635d1e2-45e5-4b31-8ae2-f6acb00f943f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A New Design for the "Congratulations!" Page

[Tim Allen]

I've had the privilege of introducing Django to many people over the past
several years. A recurring theme I have noticed is that once a new Django
developer reaches the "It Worked!" page, the inevitable next question is,
"now what?"

It struck me that this page is valuable real estate for the newcomer. Since
my eye for design is practically non-existent, I worked with a talented
colleague and we came up with an idea to replace the "It Worked!" page.
Here is a link:

https://chadwhitman.github.io/congrats/django/

Some of the goals we wanted to achieve:

   - Provide a friendly design using the same themes as the Django Project
   website.
   - Ensure the developer is using the current version of Django. Many
   tutorials found through Google are for older versions of Django.
   - Provide links to the current versions of the documentation,
   introductory polling tutorial, and community.
   - Include the release notes for the current version of Django.
   - Focus on the new Django developer, as many seasoned Django developers
   will using other methods for starting projects.


While it is doubtful that many would see this screen on a small device, it
is fully responsive as well. It is self-contained, with minified CSS and
SVG icons, and a total size of 20k, so it shouldn't provide much bloat at
all.

We're looking for feedback, and if the community thinks it is an
improvement, we'll be happy to work on a pull request. A big hat tip to my
colleague Chad Whitman for his design talents.

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/CACrTqc1%3Du9oG9At%3DY-SxavYtvwTb6qN5dSAUDJL0AkxJrKvQQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending Django models with Schevo

[Tim Allen]

Hi Etienne, like Tim G. said, you'll probably have better luck with the 
django-users mailing list. This group is for development discussion of core 
Django itself.

You may also want to reconsider using Schevo; I remember hearing about it 
long ago, but it doesn't appear that is has been actively developed in a 
decade, and only supports up to Python version 2.5, which has not been 
supported in years.

Good luck. Regards,

The other Tim

On Saturday, February 18, 2017 at 5:15:59 AM UTC-5, Etienne Robillard wrote:
>
> Hi Tim,
>
> I'm looking for technical comments about developing Django models classes 
> using the Schevo DBMS.
>
> http://www.isotopesoftware.ca/documentation/libschevo/
>
> I would like to use this like so:
>
> $ manage.py schevo test myapp
>
> $ manage.py schevo db-update myapp
>
> $ manage.py schevo shell 
>
> The "schevo" string is a command to access the Schevo API from the Django 
> management script.
>
> The Django model classes I need would provide a bridge to the Schevo 
> databases.
>
> Kind regards,
>
> E
>
>
> Le 2017-02-17 à 19:20, Tim Graham a écrit :
>
> Hi Etienne, I'm not sure exactly what type of response you're looking for 
> or if this is on-topic for the Django developers mailing list, which 
> pertains to the development of Django itself. django-users seems more 
> appropriate unless you're proposing some feature for Django.
>
> On Friday, February 17, 2017 at 3:57:42 PM UTC-5, Etienne Robillard wrote: 
>>
>> Hi, 
>>
>> I'm planning to extend django-hotsauce to support a generic "model" API. 
>> I would like to reuse the Django models API to support Schevo databases. 
>> Ideally, I would like to introspect into my reusable Django apps to 
>> discover configured features. Importing and exporting data from/to 
>> Schevo databases using JSON fixtures would also be a great addition. 
>>
>> Any ideas if Django 1.10 can be used for this? 
>>
>> Kind regards, 
>>
>> Etienne 
>>
>> -- 
>> Etienne Robillard 
>> tka...@yandex.com 
>> http://www.isotopesoftware.ca/ 
>>
>> -- 
> 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/f907064e-f4c4-4c73-aa31-0204b7ee1c12%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> Etienne robillardtka...@yandex.com http://www.isotopesoftware.ca/
>
>

-- 
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/9edba0a4-b1e7-4509-b105-9e7404c5dc46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: DEP 7 - dependency policy

[Tim Allen]

This makes sense, and the DEP looks great. Just a few thoughts:

- Django has always had dependencies, just external to PyPI. Python itself 
is the obvious one. While not absolutely required for Django, a database 
driver stack is another (psycopg2, mysql-connector, pyodbc, etc). Perhaps 
we can look into the maturity levels of these existing dependencies for 
some concrete ideas on what sort of requirements will be needed for stable 
Python packages to be included.

- This should go without saying, but to be explicit, it may be worth noting 
that any packages must support the same versions of Python that current 
Django versions support, including LTS releases. I have actually run into a 
similar issue in the past not directly with Django, but relating to 
developer environments (Red Hat 6.x having system Python v. 2.6.6, no 
longer being compatible with virtualenv's newer versions). This is 
tangentially related to the "Backwards compatible" section of the DEP.

Regards,

Tim

On Saturday, November 5, 2016 at 8:24:28 AM UTC-4, Jacob Kaplan-Moss wrote:
>
> Hi all -
>
> DEP 7 proposes a new dependency policy. In a nutshell, the policy is: 
> Python packaging is good now. Django can have dependancies.
>
> For full details, please check out the DEP: 
> https://github.com/django/deps/blob/master/draft/0007-dependency-policy.rst
>
> I'd appreciate any comments and feedback y'all have before I submit this 
> to the technical board for review. In particular, there are a couple of 
> things I'd like feedback on:
>
> - Are my criteria for "maturity" appropriate? Will they cover use-cases we 
> want to cover? 
>
> - Do we need more policy/process around dealing with potential abandonment 
> issues? 
>
> Thanks,
>
> Jacob
>

-- 
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/5cc46737-58f9-4cd4-8a84-f9de0052fbf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Box - A vagrant virtual machine for testing Django

[Tim Allen]

I'd be happy to contribute configuration for connecting Django to SQL 
Server. I've had to deploy this for some projects at work that don't (yet) 
use PostgreSQL. This sounds like a fantastic tool for testing, as well as 
examples for people just getting started; wiring up a database for the 
first time can be a challenge, with many moving parts in several layers.

-- 
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/f97a341f-c0ff-45c0-9cac-80d6111def58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend support for long surnames in Django Auth

[Tim Allen]

Our main database in my division contains about 150,000 users total - from 
across the world. Although the distribution is heavily weighted towards 
North America and Europe, we do have a fair amount of Asian schools, and 
one from Brazil. Many of these schools also have international students. I 
hope some insights on these data may prove valuable.

We currently have fields for first name (max length=50), last name (max 
length=50), and full name (max length=100). These are in SQL Server (we are 
converting to PostgreSQL, one step at a time) and of type NVARCHAR, so 
that's inclusive of byte length for Unicode characters.

Even with our single Brazilian school, I can see the need for a last name 
field longer than 50 characters, and definitely longer than 30. We also 
have quite a few users who have chosen to populate their last name fields 
with input like 'Lastname (Sr John Huntsman Prof of Awesomeness)' in their 
last name field, where they've abbreviated due to the field length. Yes, 
that would be more appropriate for a title field, but I suspect we are not 
alone in having users exhibit / want this flexible behavior, so it appears 
everywhere their name does.

My two cents? Setting username, first_name, and last_name in Django to a 
max_length of ~192 would cover the most users, be backwards compatible even 
with MySQL < 5.0.3, and give a lot of flexibility to the developer. It is 
quite possible I've missed something, but figured I'd throw some 
observations based on our users out there. Thanks for the discussion.

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/5bdcc162-fb9a-4f3f-afc7-2d4129667f8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Conditions DEP

[Tim Allen]

Hi Connor,

How would you prefer suggested tweaks to your proposal? Since it is on 
GitHub, would you prefer pull requests? Thank you for taking the initiative!

Regards,

Tim

On Sunday, June 5, 2016 at 10:52:57 PM UTC-4, Connor Boyle wrote:
>
> I'd like to make a proposal for the addition of a major new feature to 
> Django. Back in late March of this year, I wrote an original Google 
> Summer of Code proposal 
>  that 
> received some interest from several members of the community, but neither I 
> nor this proposal were selected for GSoC. A community member (iirc it was 
> Florian Apolloner) told me to put the proposal in the form of a DEP.
>
> For those not previously introduced (or who need a reminder), this 
> proposal is for a standardized system of "conditions"–dynamic rules written 
> in plain Python–which would be used primarily to evaluate whether an action 
> (in most cases, the execution of a view) should be allowed. Comparable 
> features include Django-Rules and the permissions system in Django Rest 
> Framework.
>
> The current version of the DEP is attached here 
> .
>  
> I am currently seeking at least a shepherd and hopefully other 
> implementors. Any and all thoughtful critique would be highly appreciated.
>
> Thanks,
> Connor
>

-- 
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/1d1e07c4-7995-46d8-9296-741f8760ce75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DjangoCon US 2016

[Tim Allen]

Just a reminder the today is the last day to register for DjangoCon at 
Early Bird rates. Tomorrow, prices will increase by $50 per ticket. To 
register, click here:

https://2016.djangocon.us/tickets/

Prices are affordable for the 5 days, starting at $195 for our diversity 
rate. The speakers lineup has been announced, and has something for 
everyone, whether you're a seasoned Django developer, just dipping your toe 
in the pool, or not a developer at all. There should be some familiar names 
on the list. :) I've included a full list of talks below. We sincerely hope 
you can make it. Feel free to email me off-list with any questions you may 
have.

Regards,

Tim

---

TALK LIST:

A new look into APIs - Graphene (Syrus Akbary)
It Is Darkest Before Dawn: Alcoholism and Addiction in Tech (Timothy Allen)
The impact of women learning to code in developing countries: benefits and 
challenges. (Aisha Bello & Ibrahim Diop)
Full Auto Django: scaling and HA with Docker, Kubernetes and Atomic (Josh 
Berkus)
Happy Asset Deployments with Webpack & Django (Scott Burns)
Git in Control, Version Control and How it Could Save Your Life (Rachell 
Calhoun)
The Fraud Police are Coming: Work, Leadership, and Imposter Syndrome 
(Amanda Clark & Briana Morgan)
Websockets: Intro to messaging. (Josue Balandrano Coronel)
High-Availability Django (Frankie Dintino)
Building Dynamic Dashboards with Django and D3 (Clinton Dreisbach)
Beyond PO: How to make Django work for right-to-left languages (Cho Garcia 
& Payam)
Solving problems with Django Forms. (Kirt Gittens)
I Didn’t Know QuerySets Could Do That (Charlie Guo)
Geospatial Analysis with GeoDjango (Don Holloway)
SSL all the things (Markus Holtermann)
An Intro To Web Accessibility In Django (Annalee Flower Horne)
Readability Counts (Trey Hunner)
People are coming to my beginning workshop, what now? (Nicholle James)
Frog and Toad Learn About Django Security (Philip James)
Things your mother didn’t teach you about sharing your toys (Russell 
Keith-Magee)
This Old Pony: Working with Legacy Django Apps (Ben Lopatin)
Walking Down the A11y Road - Lessons Learnt from Working on Accessibility 
of a Django Project (Radina Matic)
Django and React: Perfect Together (Jack McCloy)
Stress Testing your Code of Conduct in Production (Baptiste Mispelon & Ola 
Sendecka)
Django Supporting Virtual Reality Game Development (Rudy Mutter)
Django, Python, and Health Care Data (Becca Nock)
>From Developer to Manager (Sean O’Connor)
Dispelling the ‘Genius Programmer’ Myth Through Code Review (Ashwini 
Oruganti)
Design for Non-Designers (Tracy Osborn)
Rub-a-Dub Rubber Duck: Don’t Be Afraid to Debug! (Anna Ossowski)
The City as Cyborg: a history of Civic Tech in the first quarter of the 
21st Century (Mjumbe Poe)
The Full Stack of User Experience (Alicia C. Raciti)
Spicing up Django: An introduction to Mezzanine CMS (Ed Rivas)
MBaaS Framework: Built with Django & Django REST Framework (Kartikeya Rokde)
Healthy Minds in a Healthy Community (Erik Romijn)
Building JSON APIs with Django / Pinax (Brian Rosner)
How We Used NLP and Django to Build a Movie Suggestion Website & Twitterbot 
(Vince Salvino)
Django for IoT: From hackathon to production (Anna Schneider)
Angular 2 and You (Pam Selle)
Pushing the Pony’s boundaries — Django Admin Customization (Ola Sitarska)
Sign Me Up - Choosing & using a registration package for your Django 
project (Eleanor Stribling)
Just Enough Typography (Joni Trythall)
Under the Hood of Modern CSS Frameworks (Michael Trythall)
Atomic Wagtail (Kurt Wall)
Making the most Out of Code Reviews (Mariatta Wijaya)
Entomology 101: Effective Bug Hunting (Frank Wiles)

On Wednesday, March 23, 2016 at 11:58:25 AM UTC-4, Andrew Pinkham wrote:
>
> We are pleased to announce that DjangoCon US will be hosted by the Wharton 
> School at the University of Pennsylvania in Philadelphia from July 17-22!
>
> We are looking for suggestions about topics that you would like to see at 
> DjangoCon. If you have a suggestion, please add it to this gist document 
> .
>
> The call for proposals is open! 
>  We want 
> to hear about your experience with and around Django. However, talks: 
>
> - Don't need to be about Django specifically
> - Don't need to be 100% fleshed out.
> - Don't need to be about software directly
> - Don't need to be advanced
>
> Apply now! The deadline is April 18th. 
> 
>
> Never spoken before? Not a problem! There are speaker mentors that will 
> help you (see the link above).
>
> Is cost a concern? Not a problem! Apply for financial aid (deadline April 
> 25th). 
>
> You can follow all the latest on Twitter .
>
> Hope to see you in Philly!
>
> Andrew
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

If people are planning on being in Philadelphia around the time of 
DjangoCon this summer (July 17th - 22nd), I'd be happy to arrange space for 
a meeting / code sprint and provide food. Django sprints are on July 21st / 
22nd which would be ideal; or the weekend afterwards. I'm on the DjangoCon 
organization team and arranging for the space for the conference already, 
so I'd be happy to help out with logistics.

Just a thought, since several of us may be planning on being in Philly 
already. The Wharton School (full disclosure: I'm an employee) is hosting 
DjangoCon and runs Django with SQL Server, so I'm sure we'd be amenable to 
helping out where we can. More details: https://2016.djangocon.us

Both Tims on this thread are near Philadephia. :) Regards,

Tim A.

On Tuesday, March 22, 2016 at 6:52:08 PM UTC-4, Vin Yu wrote:
>
> 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
>
>
>  
>
> On Friday, 11 March 2016 10:54:01 UTC-8, Tim Graham wrote:
>>
>> Yes, I wonder if Microsoft abandoned the idea of providing engineering 
>> resources to help out projects like django-mssql or if things are just 
>> moving really slowly? I'm not aware of any follow up related to that idea 
>> since Michael, Michiya, and I visited Microsoft in October.
>>
>> On Wednesday, March 9, 2016 at 9:43:16 PM UTC-5, Cristiano Coelho wrote:
>>>
>>> "Improve documentation/examples [decrease confusion]: There's already so 
>>> much awesome content out there on getting started with Django (but not many 
>>> are referencing MSSQL as the db of choice or why MSSQL is a great option)."
>>>
>>> I wouldn't think of MSSQL as a great option for django at least until it 
>>> is supported natively and not through 3rd party apps which are always 
>>> behind django updates.
>>>
>>> El martes, 8 de marzo de 2016, 23:20:58 (UTC-3), Vin Yu escribió:
>>>>
>>>> Hey Tim,
>>>>
>>>> We've gotten lots of questions about the tools when we announced SQL 
>>>> Server on Linux. I am curious; what are the DB management/development 
>>>> tasks 
>>>> that are being performed by your coworkers? What are they using SSMS for? 
>>>> I 
>>>> am interested in learning more. [Perhaps we can follow up by email as this 
>>>> seens off-topic here :) ] 
>>>>
>>>> In terms of strengthening the story for MSSQL-Django, I think there is 
>>>> a little bit of both difficulty and confusion over options; here are some 
>>>> ideas that we are working on and could solve these issues:
>>>>
>>>>- Improve documentation/examples [decrease confusion]: There's 
>>>>already so much awesome content out there on getting started with 
>>>> Django 
>>>>(but not many are referencing MSSQL as the db of choice or why MSSQL is 
>>>> a 
>>>>great option).
>>>>- Improve getting started experience [decrease difficulty]: Getting 
>>>>MSSQL for development (free and easy/fast set up) is hard today;this is 
>>>> on 
>>>>MSFT to improve this experience.
>>>>
>>>> We want to help provide better developer experiences for those who want 
>>>> to create new Django apps + MSSQL databases and if MSSQL were in the core, 
>>>> it would definitely help with that. This would increase usage and is 
>>>> something we are striving to achieve. We will continue to work with the 
>>>> community to make this happen.  
>>>>
>>>> =) , 
>>>> Vin
>>>>
>>>>
>>>> On Tuesday, 8 March 2016 10:13:34 UTC-8, Tim Allen wrote:
>>>>>
>>>>> [slightly off-topic] I'm wondering if this will extend to SQL Server 
>>>>> Management Studio. While I'm mainly a command line basher, many of 
>>>>> coworkers are married to the GUI. I've found SSMS blows the competition 
>>>>> out 
>>>>> of the water when it comes to DB management GUIs. I'm wondering if this 
>>>>> means SSMS will run on Linux (or Mac) eventually.
>>>>>
>>>>> This is cert

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

[slightly off-topic] I'm wondering if this will extend to SQL Server 
Management Studio. While I'm mainly a command line basher, many of 
coworkers are married to the GUI. I've found SSMS blows the competition out 
of the water when it comes to DB management GUIs. I'm wondering if this 
means SSMS will run on Linux (or Mac) eventually.

This is certainly very big news. I wouldn't be shocked to some day see 
Windows itself running on the Linux Kernel.

Meet, how can we help strengthen the story for MSSQL-Django? It seems we 
have a chicken and egg problem here. A very small amount of Django sites 
use SQL Server, but is that because of the difficulty in the available 
stack and confusion over options? Would usage increase if provided in core?

On Monday, March 7, 2016 at 6:03:29 PM UTC-5, Josh Smeaton wrote:
>
> Wow, that's really great news! I haven't used mssql for a number of years 
> but it was always very nice to work with. Having it available to run on 
> linux will make it much easier for the Django community to test against 
> mssql, provided we're able to get/develop an appropriate driver and 
> backend. 
>
> Cheers
>
> On Tuesday, 8 March 2016 09:37:06 UTC+11, Meet Bhagdev wrote:
>>
>> Hi all,
>>
>> On interacting with several Django developers and committers, one of the 
>> questions often came up, can I use SQL Server on non Window OS's? I wanted 
>> to share that today Microsoft announced SQL Server availibility on Linux - 
>> https://blogs.microsoft.com/blog/2016/03/07/announcing-sql-server-on-linux/
>> . 
>>
>> While there is still work needed to strengthen the MSSQL-Django story, we 
>> hope this aids more Linux developers to give SQL Server a shot. Let me know 
>> of your thoughts and questions :)
>>
>> Cheers,
>> Meet
>>
>> On Monday, February 22, 2016 at 4:54:38 PM UTC-8, Vin Yu wrote:
>>>
>>> Hey Folks, 
>>>
>>> My name is Vin and I work with Meet in the Microsoft SQL Server team. 
>>> Just wanted to let you all know we are still looking into how we can better 
>>> improve and support MSSQL for the Django framework. We’ll continue to sync 
>>> with Michael and let you know of any updates soon. 
>>>
>>> Christiano and Tim - thanks for sharing your interest and sharing how 
>>> you are using Django with MSSQL. It's great to learn from your scenarios. 
>>>
>>> If you have any concerns, questions or comments feel free to reach out 
>>> to me at vinsonyu[at]microsoft.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-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/c8f8b96a-6300-4fc0-9602-1179ff79c276%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

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, sinc

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

e 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 
>>>>

Re: structural & functional review of django documentation

[Tim Allen]

Scot, you've summarized what I've run into as well beautifully. My problem 
has never been with the documentation once I find it - it has been the path 
to finding it. Another frustration is trying to find a part of the 
documentation I know I've seen before a second time. I seem to go round and 
round in link circles for a frustrating amount of time. Taxonomy here is 
important, because of the frequent use and reuse of potential search terms 
throughout the documentation.

Regards,

Tim

On Monday, January 4, 2016 at 2:45:56 AM UTC-5, Scot Hacker wrote:
>
> The written quality of the Django docs has been a selling point for years, 
> but discoverability has never been great. I wanted to add two notes:
>
> 1) The front page of the docs says docs are organized into four sections 
> (Tutorials, Topic Guides, Reference Guides,  How-To Guides). And it's been 
> proposed that we add a fifth docstring-generated API Reference as well. But 
> remember that most people looking to solve a problem under deadline start 
> with search, not taxonomy. Search results do *seem* to be labeled with the 
> section of the docs they come from, but the sections referenced don't 
>  actually correspond to the four sections we say use!  If I search for 
> "forms" I get results that claim to come from "API Reference," "Using 
> Django," "Release Notes," which don't match the names of our four sections. 
>  I propose that A) search results clearly indicate the doc sections that we 
> claim we use for organization; B) Search results be grouped by type (e.g. 
> show all results from Using Django first, followed by all results from API 
> Reference)... or whatever. Or a user could use checkboxes to select which 
> section of the docs they want to search. Or faceted search results so users 
> can quickly toggle or filter the sources of the search results? There are a 
> lot of ways to solve this - just pointing out that our search experiences 
> could be  sharper and more customizable.
>
> 2) I've encountered a number of situations where search didn't help 
> because I didn't yet know enough to search for the right thing. I remember 
> early in my Django experience trying to figure out how to have a "global 
> variable" for my project and that search string not turning up what I 
> needed to know... because what I really should have been searching for was 
> "context processors".* I think we could make strides in search-ability 
> through the indication of a tagging system. Tags could either be controlled 
> through commits, or dynamic (users could tag topics on the fly, and a 
> weighting system would apply to search results). 
>
> * Even today, searching the docs for "context processor" does not take me 
> quickly to a clean example of how to implement a context processor - I 
> really have to dig for this information. 
>
> ./s
>
>

-- 
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/b0f50682-2c4b-42f8-a4b9-33fc3121f315%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Tim Allen]

Tim: that's definitely a big help, but still a click away. I'm just 
brainstorming here, please bear with me!

I think part of my confusion as a newbie is from the front page itself, 
at https://docs.djangoproject.com/

Now that I understand the concepts behind the documentation better (thanks 
Daniele), it doesn't appear to be very well reflected on the front page. 
There is a list of First steps, The model layer, and so on, but nothing in 
the interface that clearly lets the user know that the documentation is 
meant to be broken down into the "Tutorials / How-To / Explanation & 
Discussion / Reference" paradigm. If that's what we are trying to 
communicate, it should be shown to the user from the front of the 
documentation clearly, IMHO.

A top-down, browsable hierarchy would have been extremely useful to me when 
I was just getting started. The ToC has the kind of hierarchy I'm referring 
to (https://docs.djangoproject.com/en/1.9/contents/), but comes across to 
the user as a wall of text / links. Perhaps developing the ToC into a 
navigation menu is worth some effort?

Does anyone else feel there is far too much on the front page? An 
experienced Django dev will be more comfortable finding what they need 
within the documentation, am I alone in thinking a much more simple front 
page might be useful to the newcomer?

Regards,

Tim

On Tuesday, December 29, 2015 at 11:25:40 AM UTC-5, Tim Graham wrote:
>
> I've refined Daniele's explanation here: 
> https://github.com/django/django/pull/5888
>
> Let me know if it helps and what could be better.
>
> On Monday, December 28, 2015 at 11:31:30 PM UTC-5, Eric Holscher wrote:
>>
>>
>>
>> On Monday, December 28, 2015 at 4:52:36 PM UTC-8, Daniele Procida wrote:
>>>
>>> On Mon, Dec 28, 2015, Samuel Bishop  wrote:
>>> The main existing sections are: 
>>>
>>> * tutorials (/intro) 
>>>
>>> Tutorials take the new user by the hand through a series of steps. The 
>>> important thing isn't to explain all the steps, but to achieve something 
>>> useful with a minimum of effort. 
>>>
>>> After every step of a tutorial, the user should have something that 
>>> works, even if they barely understand what is happening (and it's not 
>>> necessary for them to understand, that can come later. What matters is that 
>>> they are successful). 
>>>
>>> * how-to guides (/howto) 
>>>
>>> How-to guides are recipes that take the user through steps in key 
>>> subjects. They are more advanced than tutorials and assume a lot more about 
>>> what the user already knows than tutorials do, and unlike documents in the 
>>> tutorial they can stand alone.   
>>>
>>> * discussion and explanation (/topic) 
>>>
>>> Aimed at explaining (at a fairly high level) rather than doing. 
>>>
>>> * reference (/ref) 
>>>
>>> Technical reference for APIs, key models and so on. It doesn't need to 
>>> explain so much as describe and instruct. 
>>>
>>>  
>> I think the above post does a good job of describing the layout, and 
>> something similar should be included in the docs. Without having read 
>> Jacob's posts on the subject, there is nothing in the official docs that 
>> gives the reader an understanding that this is how things are laid out, as 
>> far as I know.
>>
>> I think the underlying structure makes sense, and it seems that mostly 
>> people are just upset about the lack of a pure auto-generated code 
>> reference. I believe historically that this has been excluded explicitly, 
>> not because of lack of technology. There is no use of autodoc in the Django 
>> tree, even where it might make sense.
>>
>> At Django Under the Hood this year, I had a few conversations with folks 
>> about rethinking and explicitly defining these policies. I think it makes a 
>> lot of sense to write down the logic and structure behind these decisions 
>> in a DEP, and explain the layout to doc users in a few places in the 
>> documentation explicitly.
>>
>> Cheers,
>> Eric 
>>
>

-- 
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/12221065-6358-4a20-a383-60f3aac5f240%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Tim Allen]

HI Doug, I can relate to what you are saying, I had a similar experience 
when trying to find a reference for the generic FormView. Issuing a P.R. to 
improve it is on my BLOTTD (big list of things to do). I was interviewing a 
candidate last week who knows I'm a big fan of Django, and wanted to throw 
a curveball, so I asked what they thought the biggest shortcoming of Django 
is. Without hesitation, they mentioned that their current team (which is 
just starting to learn Django) had trouble with the documentation. When I 
followed up, they mentioned it all seemed to be by example, rather than 
reference, and both are useful.

It is a big fish to fry, as Tim G mentioned, but I think it can be improved 
incrementally. I've used the Django Documentation for several years, and 
this is the first I've heard of the "topics", "reference" and "how-to".

As someone who used PHP for years, one thing I always felt they got right 
was documentation. That may just be the way my mind works, however.

This is a long way of saying, I'm interesting in helping out.

Regards,

Tim

On Sunday, December 27, 2015 at 9:06:46 PM UTC-5, Doug Epling wrote:
>
> Tim --
>
> Thank you so much for the link to that blog post.  I am going away now to 
> think about that data a little, but I'll be back.
>
> I was not aware of the "topics", "reference", and "how-to" assortment.  
> But I have scanned the Table of Contents, and I find almost nothing here 
> addressing documentation 
> .  
>
> I am afraid I have caused enough trouble for now.  I need a little time to 
> digest that survey data, but I will be back.
>
> When I look at Django docs, I want to be informed as a Python programmer, 
> perhaps even a novice one.  As far as I can tell, there is no such thing in 
> Django as Forms -- forms or form either for this matter.  There is a Form 
> class, and it can instantiate any number of objects.  But THIS KIND OF 
> THING (caps for emphasis on this example) is the kernel of my frustration. 
>
> Again, many thanks Tim, your last post is very helpful to me.
>
> On Friday, December 18, 2015 at 7:02:56 PM UTC-5, Doug Epling wrote:
>>
>> I filed bug report 
>> #25952 but apparently it 
>> was in the wrong place.  And I referenced this post 
>> ,
>>  
>> but I was thinking it was this group ... I wonder how that happened?
>>
>> So I am hereby suggesting that the road map for the v. 2.0 release 
>> include revamped documentation.  
>>
>> It should begin as soon as possible with the somewhat standard best 
>> practice of collecting "find what you were looking for" or "was this page 
>> helpful" or "rate this page on its organization, clarity, brevity, etc." 
>> data on every single existing page.  
>>
>> It might also be helpful to evaluate how different audiences access the 
>> docs.  Tutorials are great -- module and class libraries, not so much.
>>
>> With resulting user feedback along with expert categorization of 
>> documentation use cases, as with any writing exercise, there must be an 
>> outline.  The existing outline might be a good place to start.
>>
>> Oh, and those pesky deadlines, when is v. 2.0 slated for release?
>>
>>
>>

-- 
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/025ed576-59e1-45cf-9cbe-be11ee56115d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[Tim Allen]

Since we're on the topic, it'd be great if `inspectdb` also accepted a 
`--tables` option, to only move certain tables in the database. For example:

./manage.py inspectdb --tables=form_*,user_*

...to import any tables starting with 'form_' or 'user_'. Allow with the 
`--database` option, this would allow moving over certain features 
app-by-app more easily when migrating a large project, without having to do 
a "dump all, remove cruft", which can be time consuming with very large 
legacy systems.

Regards,

Tim

On Sunday, November 1, 2015 at 12:52:46 AM UTC-4, José Tomás Tocino wrote:
>
> Hi there.
>
> I have an Oracle database that I access from Django with a user with 
> limited privileges that can access some special views the DBA has set up 
> for me. I wanted to use inspectdb to automatically generate the models for 
> those views, but it didn't work.
>
> The problem is that the SQL statement that Django uses to fetch the tables 
> and views [1] for the current user does not properly return the views I 
> need because the user does not own them, and USER_VIEWS only returns those 
> VIEWS owned by the user. Not owning a table or a view should not be an 
> obstacle for automatically generating a model, so my proposal is to extend 
> the inspectdb to allow selecting what tables and views should be considered 
> for inspection. This would enable the inspection of tables and/or views 
> that the user does not own, as long as their name is known.
>
> It would be very easy to do, just add an optional positional argument to 
> the inspectdb commands for the names of the tables/views and, if it's 
> available, just inspect those tables/views instead of those returned by the 
> introspection service.
>
> Here's a patch of a possible solution:
>
> --- django/django/core/management/commands/inspectdb.py 2015-10-31 
> 20:50:57.401113597 +0100
> +++ 
> /home/jose/.virtualenvs/ori2/lib/python3.4/site-packages/django/core/management/commands/inspectdb.py
>  2015-10-31 
> 20:52:26.241112474 +0100
> @@ -19,6 +19,8 @@
>  parser.add_argument('--database', action='store', dest='database',
>  default=DEFAULT_DB_ALIAS, help='Nominates a database to '
>  'introspect. Defaults to using the "default" database.')
> +parser.add_argument('table', action='store', nargs='*', type=str,
> +help='Selects what tables or views should be 
> introspected')
>  
>  def handle(self, **options):
>  try:
> @@ -50,7 +51,12 @@
>  yield ''
>  yield 'from %s import models' % self.db_module
>  known_models = []
> -for table_name in 
> connection.introspection.table_names(cursor):
> +if options['table']:
> +tables_to_introspect = options['table']
> +else:
> +tables_to_introspect = 
> connection.introspection.table_names(cursor)
> +
> +for table_name in tables_to_introspect:
>  if table_name_filter is not None and 
> callable(table_name_filter):
>  if not table_name_filter(table_name):
>  continue
>
> Regards
>
> P.S.: sorry if I messed up any rule of the contribution guidelines, I'm 
> not used to contributing to large open source projects.
>
> [1] 
> https://github.com/django/django/blob/master/django/db/backends/oracle/introspection.py#L54
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cf7ca8ac-b1a7-46ad-9ec9-41a7cccedfb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Python 3.5 Support in Django 1.8.x?

[Tim Allen]

Since Django 1.9 will support Python 3.5, I was wondering if there are any 
plans to support Python 3.5 in Django 1.8, since it is an LTR.

I did a cursory search and didn't find anything stating yay or nay. I'm 
going to assume 1.8 only support 3.4 for now, as I've had issues with 
Python 3.5 (if, on the other hand, there will be support, I'll report this 
bugs in detail).

Can someone give me an answer or point me to a relevant discussion I may 
have missed? Thank you.

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1183445d-46c2-46a7-9324-8a6b1156c416%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - October 17, 2015

[Tim Allen]

Thanks Tim, this is a promising update. While my department is slowly 
migrating to PostgreSQL, most of the other departments are still very much 
reliant on SQL Server. Since we're a Python/Django shop for our web stack, 
better support would be very welcome. Most of our developers are on Macs, 
but we do have some on PCs, so supporting both is very much of interest to 
us. I'm sorry I couldn't join via Skype, I was looking forward to it, but a 
nasty head cold got in the way.

Old, I've attempted to improve the Windows Installation instructions in the 
Django docs and issued a PR here:

https://github.com/django/django/pull/5376

I'd very much like more feedback. It uses the Windows Python 3.5 installer 
(so should wait until 1.9), which is greatly simplified. The addition of 
the checkbox to include in the Windows path removes a problem barrier I've 
seen many times, and virtualenvwrapper-win also helps remove many stumbling 
blocks with pathing that beginners really don't need to fully understand to 
get started, in my opinion.

Regards,

Tim

On Saturday, October 17, 2015 at 8:36:25 PM UTC-4, Tim Graham wrote:
>
> Report for week ending October 17, 2015: 
>
  
>
 
>
They learned about some difficulties of installing Rails on Windows and how 
> that's really a diversity issues since most new programmers will be on 
> Windows. That's something for the Django community to keep in mind, but I 
> hope programs and tutorials like Django Girls will keep us honest.
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10e6423e-13bb-4c36-b8a1-d42c159bf4df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d54bc172-6c90-407e-a0aa-591fb280c0cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91bba226-f8df-479c-8265-3d021d0cc383%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

Sorry to have missed meeting you at DjangoCon, Meet, but I'll add my 
findings here to the record.

By way of background, I work at The Wharton School, where we're a 
Python/Django (on RHEL) and SQL Server shop. I was responsible for 
implementing a working configuration for Django, starting with version 1.6, 
including building Vagrant boxes for developers which had to be 'vagrant up 
plug-and-play' ready to go. We've had pretty good success with the stack 
we're now using, but hit quite a few pain points and found many points 
where things can very much be improved.

First, drivers at the Linux level.

   - We've had our best luck with FreeTDS and unixODBC for reliability. 
   We've been using it successfully throughout the process.
   - We found the MS provided driver more performant, specifically when 
  dealing with large numbers of inserts.
  - The MS driver also offered features like bulk-loading of data, 
  which while not Django specific, would have still been a big win for our 
  team using Python without Django.
  - FreeTDS + unixODBC runs under any Linux distro we tested 
  (RHEL/CentOS, Ubuntu, Debian) and Solaris.
   - As mentioned, we found the MSODBC Driver for RedHat 
   (http://www.microsoft.com/en-us/download/details.aspx?id=36437) to be more 
   performant, however, ran into quite a few issues starting with Django 1.7.
   - There seem to be issues with multi-threading. Starting with Django 
  1.7, we had to run Django's runserver with the '--nothreading' option.
  - We ran into further issues with SQLRowCount returns from the 
  driver. These rendered it unusable.
  - Only supports RedHat, but also works on CentOS. We'd prefer one 
  that at least also works on Ubuntu/Debian (a definite must for the Django 
  community).
  - The driver is closed-source.
   - A note about FreeTDS: while FreeTDS 0.95 support TDS Version 7.3, as 
   does pyodbc, we had to stick with TDS Version 7.2, as any stack we tried 
   mapped to incorrect column types when switching to 7.3, which supports new 
   SQL Server 2008 column types. I haven't had the time to dig deeper, map 
   correctly, and issue a P.R. on this one. Additionally, TDS version numbers 
   are very confusing to users (see my Stack Overflow responses, heh). At one 
   point in time, FreeTDS has named the new TDS version "8.0" before Microsoft 
   made an official declaration; Microsoft then called it "7.2". While often 
   this will not affect configuration, now that 7.3 is support in FreeTDS 
   0.95, if "8.0" is entered in configuration, it is now default to "7.3" 
   which causes issues, and the configuration in Django, odbc.ini, and 
   freetds.conf must all explicitly state "7.2".

Regardless of the driver chosen (FreeTDS+unixODBC or MSODBC), we ended up 
having to use pyodbc instead of pymssql:

   - 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.
   
To summarize, here's what we now use:

   - FreeTDS 0.91 - 0.95 (dependent on RedHat/CentOS version)
   - unixODBC (dependent on RedHat/CentOS version)
   - pyodbc
   - django-pyodbc-azure
   
It works well for us, but we've had to make compromises, and the promise of 
better performance we've seen in certain scenarios is tempting. If I were 
building a wish list, here's what I'd like to see, for performance and 
ease-of-installation:

   - Native driver to replace FreeTDS + unixODBC for SQL Server connections 
   that is supported and runs on more than just RedHat/CentOS, preferably open 
   source!
   - Easy, prompt free option for install: I had to hack to install to 
   avoid having to respond to interactive prompts in Vagrantfiles, Chef 
   recipes, etc.
   - Eventual inclusion in EPEL, etc, for yum or apt-get installs.
   - Python package (to replace pyodbc with one that supports SQL Server 
   functionality and performance)
   - Django-Python package (to replicate django-pyodbc-azure's mappings to 
   the pyodbc replacement)
   - Support bcp, SSIS, DATE data type, FILTERED and SPATIAL (GeoDjango, 
   anyone?) index types, easy Stored Procedure calls, OUTPUT variables, and 
   more I can't remember off the top of my head.

These would also be big wins for users of other languages / frameworks, 
such as PHP and Ruby web frameworks, Flask, etc, who use SQL Server.

So there's