Re: django-mssql present and future

[Aymeric Augustin]

Hi Michael,

Thanks for this initiative!

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

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

Best regards,

-- 
Aymeric.

> On 23 May 2016, at 20:57, Michael Manfre  wrote:
> 
> There are two parts to this email. First relates to the current state of 
> django-mssql. A version of the backend that supports Django 1.8 will be 
> released in the next few weeks. I apologize for the delay, but my ability to 
> focus on the project was basically non-existent for nearly a year due to 
> personal reasons. The backend is currently failing some of Django's test 
> suite and will likely be released before all of the issues are resolved. The 
> biggest unresolved issues right now relate to certain schema migrations and 
> some failing tests related to prefetch related that I haven't had time to 
> investigate yet. I plan on releasing with a list of known bugs, so if you use 
> this backend, please test the latest commits against your project and let me 
> know if you run in to any issues. Post your found errors on the django-mssql 
> issue tracker [1]. I will not release if there are any data corruption or 
> other blocking level bugs. I'm planning this to be the last major release 
> using adodbapi and the underlying ADO drivers.
> 
> [1] https://bitbucket.org/Manfre/django-mssql 
> 
> 
> Moving forward, django-mssql will be rewritten from scratch to use the 
> Microsoft developed ODBC drivers. These drivers are officially supported by 
> Microsoft and will be cross platform; Windows and Linux support exists and 
> OSX support is currently being worked on. Despite using ODBC drivers, this 
> backend will specifically target MSSQL to take advantage of any features or 
> performance improvements that are possible, and to reduce the support 
> overhead of working against any random database that provides an ODBC 
> interface. Microsoft has stated their willingness to contribute engineering 
> resources towards this backend.
> 
> I'd like this soon to be created repo to live under Django's github account 
> and to start the conversation about if this is desirable and what that means 
> for the backend and Django.
> 
> Why start from scratch? Sometimes the slate needs to be wiped clean to remove 
> mistakes of the past. Django-mssql has accumulated a lot of crufty code over 
> the years for various reasons. The existing ODBC backends are in various 
> states of support with slightly differing goals; generic ODBC, Azure 
> specific, etc. To me the most important reason is, I want to start from 
> scratch to help document what is involved with creating a database backend.
> 
> One concern that has been previously raised relates to handling regressions. 
> It is my expectation that individual commits to Django would be allowed to 
> break the backend's tests, but that they will be resolved before release.
> 
> If you have questions related to MSSQL or what are the expectations for 
> having an officially support Django database backend, please share them.
> 
> Regards,
> Michael Manfre
> 
> 
> 
> -- 
> 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/CAGdCwBsj6SGFqwKR7NFUMb0taExD8LGRcJtU7PPqNvcv5GvPtQ%40mail.gmail.com
>  
> .
> 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 gro

Re: django-mssql present and future

[Marc Tamlyn]

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

On 27 May 2016 at 08:24, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Michael,
>
> Thanks for this initiative!
>
> I like the idea of hosting this new project in the Django organization. I
> think there’s a lot of value in having a good SQL Server backend for
> Django, implemented according to Microsoft’s recommendations, and little
> reason to encourage competition in this space — there aren’t that many ways
> to implement such a library.
>
> However I’m wary of deciding that a non-existent-yet library is the
> endorsed solution for using SQL Server from Django. It may be best to wait
> until it has reached feature parity with django-mssql and received some
> amount of real-world testing to move it there.
>
> Best regards,
>
> --
> Aymeric.
>
> On 23 May 2016, at 20:57, Michael Manfre  wrote:
>
> There are two parts to this email. First relates to the current state of
> django-mssql. A version of the backend that supports Django 1.8 will be
> released in the next few weeks. I apologize for the delay, but my ability
> to focus on the project was basically non-existent for nearly a year due to
> personal reasons. The backend is currently failing some of Django's test
> suite and will likely be released before all of the issues are resolved.
> The biggest unresolved issues right now relate to certain schema migrations
> and some failing tests related to prefetch related that I haven't had time
> to investigate yet. I plan on releasing with a list of known bugs, so if
> you use this backend, please test the latest commits against your project
> and let me know if you run in to any issues. Post your found errors on the
> django-mssql issue tracker [1]. I will not release if there are any data
> corruption or other blocking level bugs. I'm planning this to be the last
> major release using adodbapi and the underlying ADO drivers.
>
> [1] https://bitbucket.org/Manfre/django-mssql
>
> Moving forward, django-mssql will be rewritten from scratch to use the
> Microsoft developed ODBC drivers. These drivers are officially supported by
> Microsoft and will be cross platform; Windows and Linux support exists and
> OSX support is currently being worked on. Despite using ODBC drivers, this
> backend will specifically target MSSQL to take advantage of any features or
> performance improvements that are possible, and to reduce the support
> overhead of working against any random database that provides an ODBC
> interface. Microsoft has stated their willingness to contribute
> engineering resources towards this backend.
>
> I'd like this soon to be created repo to live under Django's github
> account and to start the conversation about if this is desirable and what
> that means for the backend and Django.
>
> Why start from scratch? Sometimes the slate needs to be wiped clean to
> remove mistakes of the past. Django-mssql has accumulated a lot of crufty
> code over the years for various reasons. The existing ODBC backends are in
> various states of support with slightly differing goals; generic ODBC,
> Azure specific, etc. To me the most important reason is, I want to start
> from scratch to help document what is involved with creating a database
> backend.
>
> One concern that has been previously raised relates to handling
> regressions. It is my expectation that individual commits to Django would
> be allowed to break the backend's tests, but that they will be resolved
> before release.
>
> If you have questions related to MSSQL or what are the expectations for
> having an officially support Django database backend, please share them.
>
> Regards,
> Michael Manfre
>
>
>
> --
> 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/CAGdCwBsj6SGFqwKR7NFUMb0taExD8LGRcJtU7PPqNvcv5GvPtQ%40mail.gmail.com
> 
> .
> 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.

Support of model_object.delete(cascade=True)

[Sven R. Kunze]

Hi everybody,

That's my first proposal for Django, so I hope it's in the right shape. :)


Even though we have on_delete=PROTECTED on several models fields for a very 
good reason, there are circumstances where we want to circumvent this 
restriction for a very good reason, too. And we are 110% sure that this is 
a safe operation.

Tim already suggested to do this manually but this is very tedious for 
larger database structure as we have. We already wrote a generic function 
which provides that capability but we would appreciate a Django-bulitin 
functionality for this as we duplicate some Django-internal code.


Note 1: overriding Model.delete() does not help as we needed it (this time) 
in a backward migration to clean up what has been created in a forward 
migration. Migrations don't expose model-overriden functions.
Note 2: discussion started here: https://code.djangoproject.com/ticket/26664


Would this be valuable addition to Django?


Best,
Sven

-- 
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/1f9fc323-9911-4d79-bf02-0a669360eb8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New CharField attribute to handle CharField(null=True, blank=True, unique=True) in model forms

[Shai Berger]

Hi,

On Thursday 19 May 2016 06:01:30 Jon Dufresne wrote:
> 
> Occasionally I'll need to define a CharField on a model that is unique but
> also allow blank values. At the database level, this is easily handled by
> storing NULL for the blank values. (Storing the empty string multiple times
> will result in a DB unique constraint violation.) This use case has
> surfaced several times as evident by the 9 year old ticket #4136 [1].
> 
> I have created a POC solution to the ticket at PR 6624 [2]. The change adds
> the attribute "empty_value" to forms.CharField. The value specified by
> empty_value is used as the Python empty value for the field. This value
> defaults to the empty string (current behavior) but could also be changed
> to None. The change also modifies model forms to set empty_value to None
> for CharField when null=True is set. The model forms change allows the use
> of the admin to save blank, unique char values without unique constraint
> violations.
> 

I've added some comments on the PR. The TL;DR is that this causes some 
problems for Oracle, where empty strings are always saved as nulls, but I 
think we can solve most of the issues and document around the others.

Shai.

> 
> [1] https://code.djangoproject.com/ticket/4136
> [2] https://github.com/django/django/pull/6624

Re: django-mssql present and future

[charettes]

Hi Michael,

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

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

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

Exciting stuff,
Simon

Le lundi 23 mai 2016 14:57:35 UTC-4, Michael Manfre a écrit :
>
> There are two parts to this email. First relates to the current state of 
> django-mssql. A version of the backend that supports Django 1.8 will be 
> released in the next few weeks. I apologize for the delay, but my ability 
> to focus on the project was basically non-existent for nearly a year due to 
> personal reasons. The backend is currently failing some of Django's test 
> suite and will likely be released before all of the issues are resolved. 
> The biggest unresolved issues right now relate to certain schema migrations 
> and some failing tests related to prefetch related that I haven't had time 
> to investigate yet. I plan on releasing with a list of known bugs, so if 
> you use this backend, please test the latest commits against your project 
> and let me know if you run in to any issues. Post your found errors on the 
> django-mssql issue tracker [1]. I will not release if there are any data 
> corruption or other blocking level bugs. I'm planning this to be the last 
> major release using adodbapi and the underlying ADO drivers.
>
> [1] https://bitbucket.org/Manfre/django-mssql
>
> Moving forward, django-mssql will be rewritten from scratch to use the 
> Microsoft developed ODBC drivers. These drivers are officially supported by 
> Microsoft and will be cross platform; Windows and Linux support exists and 
> OSX support is currently being worked on. Despite using ODBC drivers, this 
> backend will specifically target MSSQL to take advantage of any features or 
> performance improvements that are possible, and to reduce the support 
> overhead of working against any random database that provides an ODBC 
> interface. Microsoft has stated their willingness to contribute 
> engineering resources towards this backend.
>
> I'd like this soon to be created repo to live under Django's github 
> account and to start the conversation about if this is desirable and what 
> that means for the backend and Django.
>
> Why start from scratch? Sometimes the slate needs to be wiped clean to 
> remove mistakes of the past. Django-mssql has accumulated a lot of crufty 
> code over the years for various reasons. The existing ODBC backends are in 
> various states of support with slightly differing goals; generic ODBC, 
> Azure specific, etc. To me the most important reason is, I want to start 
> from scratch to help document what is involved with creating a database 
> backend.
>
> One concern that has been previously raised relates to handling 
> regressions. It is my expectation that individual commits to Django would 
> be allowed to break the backend's tests, but that they will be resolved 
> before release.
>
> If you have questions related to MSSQL or what are the expectations for 
> having an officially support Django database backend, please share them.
>
> Regards,
> Michael Manfre
>
>
>

-- 
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/ca167d4b-f9bc-49c0-81bb-337c070941ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support of model_object.delete(cascade=True)

[charettes]

Hi Sven,

I agree with Tim about the fact such an option could be dangerous as you
can't control the extent of the cascade.

We removed the depth parameter of `QuerySet.select_related()` method for
similar reasons and in this case you only ended up with a slow query not
possibly purged data.

They're have been a couple of issues reported related to cascade deletion
in the past and most of the affected users we're saved by the enforced
constraints at the database level. I'm afraid the addition of such an option
could lead unexperienced developers to always pass cascade=True when
they encounter a foreign key constraint check failure.

> overriding Model.delete() does not help as we needed it (this time) in a 
backward
> migration to clean up what has been created in a forward migration. 
Migrations
> don't expose model-overriden functions.

Could simply define this feature a as imported function that takes a model 
instance
or define a model mixin witht the overriden `delete(cascade)` method? The 
autodetector
should include it in the model bases.

Cheers,
Simon

Le vendredi 27 mai 2016 08:49:42 UTC-4, Sven R. Kunze a écrit :
>
> Hi everybody,
>
> That's my first proposal for Django, so I hope it's in the right shape. :)
>
>
> Even though we have on_delete=PROTECTED on several models fields for a 
> very good reason, there are circumstances where we want to circumvent this 
> restriction for a very good reason, too. And we are 110% sure that this is 
> a safe operation.
>
> Tim already suggested to do this manually but this is very tedious for 
> larger database structure as we have. We already wrote a generic function 
> which provides that capability but we would appreciate a Django-bulitin 
> functionality for this as we duplicate some Django-internal code.
>
>
> Note 1: overriding Model.delete() does not help as we needed it (this 
> time) in a backward migration to clean up what has been created in a 
> forward migration. Migrations don't expose model-overriden functions.
> Note 2: discussion started here: 
> https://code.djangoproject.com/ticket/26664
>
>
> Would this be valuable addition to Django?
>
>
> Best,
> Sven
>

-- 
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/27448ccf-2990-441d-affd-a25c46ff0f10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-mssql present and future

[Michael Manfre]

Aymeric wrote:

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

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

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

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

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

Marc wrote:

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

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

On Fri, May 27, 2016 at 10:37 AM charettes  wrote:

> I agree, such documentation is definitely lacking and even if it wont be
> commonly used it's invaluable for the rare developers needing it.
>
> Are you planning to include it in the official Django documentation?
>

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

Regards,
Michael Manfre

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

Re: django-mssql present and future

[Aymeric Augustin]

Hi Michael,

On 27 May 2016, at 20:44, Michael Manfre  wrote:

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

Fair enough :-)

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

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

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

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

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

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

Best regards,

-- 
Aymeric.


-- 
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/019F5610-1AAB-4E8B-9273-32EEAD237AC1%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.