Re: Improving MSSQL and Azure SQL support on Django

[Aymeric Augustin]

Hello Meet,

On 21 août 2015, at 19:39, Meet Bhagdev  wrote:
  
> We’d love for Django users to have a solid option to use MSSQL and Azure SQL 
> if they wish, and it would be great to make this option a reality.

Even though this isn’t what you’re asking for :-) I’ll take this opportunity to 
summarize the landscape for combining Django and MSSQL / Azure SQL, as far as I 
understand it.

There’s a good option for MSSQL or Azure SQL users running Django on Windows: 
https://bitbucket.org/Manfre/django-mssql 
. (Perhaps it could be made even 
better, but from my perspective, it’s solid.)

There’ve been talks of making it more official. But no consensus has been found 
yet. The main difficulty is that very few Django committers use Windows as a 
primary OS, perhaps two out of fifty. Most of us don’t even own a Windows 
license. We face a similar issue with our continuous integration. Currently 
it’s running on Linux. We lack the skills and money to run Windows and SQL 
Server. (Sponsoring in the form of Azure SQL credits for the purpose of testing 
Django may solve parts of this problem, if using a remote database isn’t too 
slow for test suite’s workload.)

There isn’t such a clear story for running Django on Linux. This led me to 
write https://github.com/aaugustin/django-pymssql 
. Alternatives include 
https://github.com/denisenkom/django-sqlserver 
 and 
https://github.com/lionheart/django-pyodbc 
.

I can’t say django-pymssql is solid. But it works and it shows that 
django-mssql could be made cross-platform with limited effort, subject to the 
quality of the underlying libraries: https://github.com/pymssql/pymssql 
 and https://github.com/FreeTDS/freetds 
. However my interest has faded since I 
left the company where I had this use case. Furthermore testing is very 
painful. I'm running SQL Server Express in a VM. Tests are about 20 times 
slower than with PostgreSQL or MySQL. As a consequence Django’s test suite took 
about 2 hours. 

I appreciate the invitation. Unfortunately I live a bit too far to make the 
trip conveniently. I’m still interested in making Django work out of the box 
with SQL Server like it does with Oracle. (That’s for historical reasons: some 
people gathered and made it happen). I believe interoperability with SQL Server 
is key for using Django in the medium-sized companies where SQL Server is the 
obvious choice of database server.

I hope this helps. Thanks for reaching out!

-- 
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-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/88E01BCF-14BA-4DF5-80E1-E4457F219922%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Tim Graham]

I agree it would be great to get some help running the Django tests on 
Windows. I run them in a local virtual machine every so often, but I would 
love to be able to delegate fixing Windows issues. Meet, can your team 
provide ongoing help with fixing Windows-specific issues in Django, even if 
they aren't related to MSSQL/Azure? That is something where we've had a 
hard time finding volunteers to help with and is obviously important if we 
want to claim 1st-class support for Windows.

I don't have any experience with MSSQL/Azure, but I could probably attend 
the October 13-15 event at Microsoft if you think my participation would be 
valuable and if the DSF were to approve the time commitment as part of the 
fellow duties.

On Saturday, August 22, 2015 at 6:28:58 AM UTC-4, Aymeric Augustin wrote:
>
> Hello Meet,
>
> On 21 août 2015, at 19:39, Meet Bhagdev > 
> wrote:
>   
>
> We’d love for Django users to have a solid option to use MSSQL and Azure 
> SQL if they wish, and it would be great to make this option a reality.
>
>
> Even though this isn’t what you’re asking for :-) I’ll take this 
> opportunity to summarize the landscape for combining Django and MSSQL / 
> Azure SQL, as far as I understand it.
>
> There’s a good option for MSSQL or Azure SQL users running Django on 
> Windows: https://bitbucket.org/Manfre/django-mssql. (Perhaps it could be 
> made even better, but from my perspective, it’s solid.)
>
> There’ve been talks of making it more official. But no consensus has been 
> found yet. The main difficulty is that very few Django committers use 
> Windows as a primary OS, perhaps two out of fifty. Most of us don’t even 
> own a Windows license. We face a similar issue with our continuous 
> integration. Currently it’s running on Linux. We lack the skills and money 
> to run Windows and SQL Server. (Sponsoring in the form of Azure SQL credits 
> for the purpose of testing Django may solve parts of this problem, if using 
> a remote database isn’t too slow for test suite’s workload.)
>
> There isn’t such a clear story for running Django on Linux. This led me to 
> write https://github.com/aaugustin/django-pymssql. Alternatives include 
> https://github.com/denisenkom/django-sqlserver and 
> https://github.com/lionheart/django-pyodbc.
>
> I can’t say django-pymssql is solid. But it works and it shows that 
> django-mssql could be made cross-platform with limited effort, subject to 
> the quality of the underlying libraries: 
> https://github.com/pymssql/pymssql and https://github.com/FreeTDS/freetds. 
> However my interest has faded since I left the company where I had this use 
> case. Furthermore testing is very painful. I'm running SQL Server Express 
> in a VM. Tests are about 20 times slower than with PostgreSQL or MySQL. As 
> a consequence Django’s test suite took about 2 hours. 
>
> I appreciate the invitation. Unfortunately I live a bit too far to make 
> the trip conveniently. I’m still interested in making Django work out of 
> the box with SQL Server like it does with Oracle. (That’s for historical 
> reasons: some people gathered and made it happen). I believe 
> interoperability with SQL Server is key for using Django in the 
> medium-sized companies where SQL Server is the obvious choice of database 
> server.
>
> I hope this helps. Thanks for reaching out!
>
> -- 
> 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-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/f0ac4f4c-2da0-4ba6-8b1f-72bdd148e61c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - August 22, 2015

[Tim Graham]

Report for week ending August 22, 2015:

Besides the security release on Tuesday, I also spent a while debugging 
some selenium test failures with a new version of chromedriver. It turned 
out to be a combination of bugs in chromedriver as well as some issues in 
our tests. The build should be back to green after merging the pull request 
in the “Authored” section below. With four weeks until 1.9 alpha, I’ll 
start a “status of 1.9 release blockers” thread next week.

Triaged

---

https://code.djangoproject.com/ticket/25201 - Allow use_for_related_fields 
via as_manager() (accepted)

https://code.djangoproject.com/ticket/25280 - Infinite migrations created 
when using function based validators (accepted)

https://code.djangoproject.com/ticket/25287 - Multiplying and dividing 
connectors for datetime expressions are not supported by sqlite backed. 
(accepted)

https://code.djangoproject.com/ticket/25288 - Allow migrating models from 
other apps (needs info)

https://code.djangoproject.com/ticket/25290 - Warn against modifying 
objects created in setUpTestData (accepted)

https://code.djangoproject.com/ticket/25292 - "'str' object has no 
attribute '_meta'" crash in ManyToManyField.through_fields check (needs 
info)

https://code.djangoproject.com/ticket/25293 - Multi-table inheritance with 
only related fields results in invalid migration on MySQL (accepted)

https://code.djangoproject.com/ticket/17533 - When attempting to build more 
complex widgets/fields, access to form data would be helpful (duplicate)

https://code.google.com/p/chromedriver/issues/detail?id=1194 - unknown 
error: cannot determine loading status from disconnected: received 
Inspector.detached event (created)

https://code.djangoproject.com/ticket/25153 - The polls tutorial shows 
INSTALLED_APPS in incorrect order (fixed)

https://code.djangoproject.com/ticket/25279 - Make prefetch_related_objects 
a public API (accepted)

https://code.djangoproject.com/ticket/25294 - Allow custom BoundFields on 
forms (accepted)

https://code.djangoproject.com/ticket/25295 - translation.override() 
context manager doesn't return to deactivated state when there's no 
activated language (accepted)

https://code.djangoproject.com/ticket/25297 - makemessages doesn't detect 
the context of {% trans %} strings with a filter (accepted)

https://code.djangoproject.com/ticket/25299 - Admin crash with the name of 
a reverse accessor in list_display (accepted)

Authored



https://github.com/django/django/commit/8cc41ce7a7a8f6bebfdd89d5ab276cd0109f4fc5
 
- Fixed DoS possibility in contrib.auth.views.logout()

https://github.com/django/django/pull/5154 - Fixed #25284 -- Documented 
removal of implicit QuerySet __in lookups.

https://github.com/django/django/pull/5161 - Fixed selenium test failures 
with chromedriver 2.18.

https://github.com/django/django/pull/5162 - Refs #24914 -- Added docs for 
more auth mixin methods.

https://github.com/django/django/pull/5163 - Fixed #24525 -- Fixed 
AssertionError in some complex queries. (in progress)

Reviewed/committed

--

https://github.com/django/django/pull/5160 - Refs #12400 -- Added 
supports_geometry_field_unique_index GIS database feature.

https://github.com/django/django/pull/5168 - Fixed #23727 -- Inhibited the 
post_migrate signals when using serialized_rollback. (added added a test + 
docs)

https://github.com/django/django/pull/5172- Fixed #25300 -- Added unit 
tests for BoundField.id_for_label

Reviews of core dev work


https://github.com/django/django/pull/5158 - Fixed #25285 -- Provided 
unknown command message with plain django-admin.py

-- 
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/07829b23-218e-4d5c-8c71-92d0c2721aa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Shai Berger]

On Saturday 22 August 2015 13:28:31 Aymeric Augustin wrote:
> 
> There isn’t such a clear story for running Django on Linux. This led me to
> write https://github.com/aaugustin/django-pymssql. Alternatives include
> https://github.com/denisenkom/django-sqlserver and
> https://github.com/lionheart/django-pyodbc.

There's also django-pyodbc-azure, a fork of django-pyodbc (actually, the 
current django-pyodbc is also a fork of the original project, which has been 
discontinued). I took the liberty to forward the message to that project.

Shai.

-- 
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/201508230053.09523.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the "easy pickings" flag in Trac

[Russell Keith-Magee]

On Fri, Aug 21, 2015 at 7:35 AM, Tim Graham  wrote:

> In my experience the "easy pickings" flag is ill-defined and insufficient
> for describing the difficulty of a ticket. I don't want to get stuck in
> categorizing tickets just for the sake of it, but I think a drop down with
> options like the following could be useful in helping contributors find
> suitable tickets:
>
> Trivial - Typos, wording tweaks, etc.
> Easy - Simple features and bugs suitable for a first-time contributor.
> Moderate - Requires a basic knowledge of Django internals.
> Hard - Requires a thorough understanding of Django internals.
> Very Hard - Refactorings or features that are difficult for experienced
> core developers.
>
> Do you think this would be useful? If so, are the selections above
> suitable?
>

My concern would be bike shedding of the difficulty. Unless the type of
change is completely objective (e.g., it's a typo vs a code/logic change)
your "easy" may be my "hard", or vice versa.

Even the "is it a bug or a feature" distinction has historically caused
problems. If the test client doesn't support a particular HTTP verb, is
that a bug (because it's not fully HTTP compliant), or a missing feature
(because we didn't say it was fully HTTP compliant)?

To my eyes, the purpose of "easy pickings" was to be a semi-curated list of
stuff that we could throw at someone who says "I want to contribute - what
should I work on?".

However, even that is a fuzzy target - a ticket may be marked "easy
pickings" because it points out a trivial misinterpretation of the HTTP
spec - but if you don't know the HTTP spec really well, that means you have
to read the RFC before you can contribute.

Part of the task of skilling someone past the "first contribution" point is
teaching them how to identify the next problem to solve.

Overall - I'm not convinced that adding more detail to this category will
be helpful.

Yours,
Russ Magee %-)

-- 
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/CAJxq84-cXkK76O5%3DxvQSM%3DoRsk7x6_8yfzcMEoh0%3DjExqAzWnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.