Re: Adding support for SQL Server

[Dave Clevenger]

I would definitely get behind official support for SQL Server. The company
I work for is all about SQL Server and not willing to consider other
options. Right now we are using the django-mssql-backend:
https://github.com/ESSolutions/django-mssql-backend which works pretty well
for our use case, but official SQL Server support would be great.

Dave

On Wed, Feb 12, 2020 at 5:44 PM Adam Johnson  wrote:

> Microsoft posted in 2015 and there was an update last April about a
> working backend that claims support for 3.0:
> https://groups.google.com/d/msg/django-developers/FbBcUCzrSZo/EoFNbR2BDgAJ
>
> Any support in core would need clear evidence of widespread demand. I
> don't think there's much demand - e.g. that backend has only 38 stars on
> GitHub.
>
> On Wed, 12 Feb 2020 at 20:33, Martynas Puronas 
> wrote:
>
>> Hey, I've been working on adding support for SQL Server to Django, since
>> the package currently being linked recommended in Django's documentation
>> has been abandoned (as well as a few others seem to be either abandoned or
>> do not have the test suite passing), and I have made some significant
>> progress on it (all of admin tests are passing, as well as aggregates,
>> inserts, deletes, updates and a few other modules). I was wondering if you
>> would be open to adding support for SQL Server, provided I could make sure
>> that the entire test suite passes, and documentation is written? Or does
>> this go against Django's technical roadmap and you would rather keep
>> support for SQL Server outside of Django in a separate package?
>>
>> Thanks!
>>
>> --
>> 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/6d98459d-9616-4343-b4fe-3eabd9ef131f%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Adam
>
> --
> 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/CAMyDDM2hna%2B%3D%3DPuHKjH0xzJmEGzReDP3DFyJwX2L2bt%3DtsR97Q%40mail.gmail.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/CADR4itK8A5Cc_NEYBZvtiECJcm4PnqFhjDL_7a2OnFBTDs2%2BNQ%40mail.gmail.com.

Relax system check on fields intermediary tables for db_table collision when database routers are installed

[Anonymous Rabbit]

Hello there,

This regards multi-database Django.

On https://github.com/django/django/pull/11630, a change was made to allow 
for multiple models with the same db_name, when a DATABASE_ROUTER is 
present. 
A ticket was open here for that issue: 
https://groups.google.com/forum/#!searchin/django-updates/29092%7Csort:date/django-updates/K1VuUaa9BUc/IDmjZoiRCQAJ
 . 
Eventually it gets marked with wontfix, but with a notice: "Feel free to 
reopen and offer a patch for evaluation if you think the implementation is 
straightforward."

I implemented the same changes of PR #11630, but with fields.E340 in mind 
(fields.E340: The field’s intermediary table  clashes with the 
table name of /..).

I would like to open a PR for it, but I'm not sure of the process I have to 
follow. Should the ticket be re-opened? Can I open the PR pointing at the 
wontfix ticket instead? Should I open a new ticket for it?

Best regards,
Xavier

-- 
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/7819a6e1-3f47-41c8-a6c0-d35de3f37578%40googlegroups.com.

Re: Relax system check on fields intermediary tables for db_table collision when database routers are installed

[Adam Johnson]

Please create a new ticket with a reference to the old one, and then a PR
against that, since your change is for a different check.

On Thu, 13 Feb 2020 at 12:15, Anonymous Rabbit  wrote:

> Hello there,
>
> This regards multi-database Django.
>
> On https://github.com/django/django/pull/11630, a change was made to
> allow for multiple models with the same db_name, when a DATABASE_ROUTER is
> present.
> A ticket was open here for that issue:
> https://groups.google.com/forum/#!searchin/django-updates/29092%7Csort:date/django-updates/K1VuUaa9BUc/IDmjZoiRCQAJ
>  .
> Eventually it gets marked with wontfix, but with a notice: "Feel free to
> reopen and offer a patch for evaluation if you think the implementation is
> straightforward."
>
> I implemented the same changes of PR #11630, but with fields.E340 in mind
> (fields.E340: The field’s intermediary table  clashes with the
> table name of /..).
>
> I would like to open a PR for it, but I'm not sure of the process I have
> to follow. Should the ticket be re-opened? Can I open the PR pointing at
> the wontfix ticket instead? Should I open a new ticket for it?
>
> Best regards,
> Xavier
>
> --
> 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/7819a6e1-3f47-41c8-a6c0-d35de3f37578%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM3-F2%3DBC4bGqiMpf2cG5F47Hn217DgV3YaVGc%2BK9_VWAg%40mail.gmail.com.

Re: Improve migration conflict detection

[caio]

Cool. If I'm understanding this correctly, it auto-resolves during 
*makemigrations*?

I'm looking for something that could handle conflicts during the *migrate* 
command, but I'm not sure if that's really possible. I guess it depends on 
how intrinsic the single-leaf-node restriction is to the whole migration 
system

Thanks!

Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye escreveu:
>
> Definitely a plus one on auto resolving migrations a test package still in 
> planning aims to solve this 
> https://github.com/jackton1/django-migration-resolver-hook
>
> On Feb 11, 2020, at 1:42 PM, Caio Ariede > 
> wrote:
>
> Hey folks,
>
> I was looking at the code used to detect conflicts in migrations [1]. It 
> seems to use a very safe approach, by avoiding with multiple node leafs in 
> the migration graph.
>
> While this is safe, I’ve been having some problems when it comes to 
> scalability when having multiple migrations created in a short period of 
> time (for the same app).
>
> Questions:
>
> 1. Are there any obvious impediments on improving the conflicts detection?
> 2. Does anyone have ideas on how to improve the conflict detection? (eg. 
> going down from app-level to model-level detection)
>
>
> Thanks!
>
>
> [1] 
> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>
> --
> Caio Ariede
> caio@gmail.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-d...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.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/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%40googlegroups.com.

Re: Relax system check on fields intermediary tables for db_table collision when database routers are installed

[Anonymous Rabbit]

Before I move forward I just to want clarify, my changes are for the same
check specified in ticket #29092. Should I still open a new ticket in lieu
of re-opening #29092?

On Thu, 13 Feb 2020 at 13:23, Adam Johnson  wrote:

> Please create a new ticket with a reference to the old one, and then a PR
> against that, since your change is for a different check.
>
> On Thu, 13 Feb 2020 at 12:15, Anonymous Rabbit  wrote:
>
>> Hello there,
>>
>> This regards multi-database Django.
>>
>> On https://github.com/django/django/pull/11630, a change was made to
>> allow for multiple models with the same db_name, when a DATABASE_ROUTER is
>> present.
>> A ticket was open here for that issue:
>> https://groups.google.com/forum/#!searchin/django-updates/29092%7Csort:date/django-updates/K1VuUaa9BUc/IDmjZoiRCQAJ
>>  .
>> Eventually it gets marked with wontfix, but with a notice: "Feel free to
>> reopen and offer a patch for evaluation if you think the implementation is
>> straightforward."
>>
>> I implemented the same changes of PR #11630, but with fields.E340 in mind
>> (fields.E340: The field’s intermediary table  clashes with the
>> table name of /..).
>>
>> I would like to open a PR for it, but I'm not sure of the process I have
>> to follow. Should the ticket be re-opened? Can I open the PR pointing at
>> the wontfix ticket instead? Should I open a new ticket for it?
>>
>> Best regards,
>> Xavier
>>
>> --
>> 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/7819a6e1-3f47-41c8-a6c0-d35de3f37578%40googlegroups.com
>> 
>> .
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/Ypks34xj1AY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAMyDDM3-F2%3DBC4bGqiMpf2cG5F47Hn217DgV3YaVGc%2BK9_VWAg%40mail.gmail.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/CADfb6NLTfKQ_h7-NovUROEK9RrYcF7UyRtcZPVrX-ZayzcHo-w%40mail.gmail.com.

Re: Improve migration conflict detection

[Adam Johnson]

I don’t think many people can answer this off the top of their heads. I
certainly can’t and I have contributed a couple things to migrations.

It’s probably quite necessary there’s only one leaf node but I can’t say
for sure.

On Thu, 13 Feb 2020 at 13:58, caio  wrote:

> Cool. If I'm understanding this correctly, it auto-resolves during
> *makemigrations*?
>
> I'm looking for something that could handle conflicts during the *migrate*
> command, but I'm not sure if that's really possible. I guess it depends on
> how intrinsic the single-leaf-node restriction is to the whole migration
> system
>
> Thanks!
>
> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye
> escreveu:
>>
>> Definitely a plus one on auto resolving migrations a test package still
>> in planning aims to solve this
>> https://github.com/jackton1/django-migration-resolver-hook
>>
>> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>>
>> Hey folks,
>>
>> I was looking at the code used to detect conflicts in migrations [1]. It
>> seems to use a very safe approach, by avoiding with multiple node leafs in
>> the migration graph.
>>
>> While this is safe, I’ve been having some problems when it comes to
>> scalability when having multiple migrations created in a short period of
>> time (for the same app).
>>
>> Questions:
>>
>> 1. Are there any obvious impediments on improving the conflicts detection?
>> 2. Does anyone have ideas on how to improve the conflict detection? (eg.
>> going down from app-level to model-level detection)
>>
>>
>> Thanks!
>>
>>
>> [1]
>> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>>
>> --
>> Caio Ariede
>> caio@gmail.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-d...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.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/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%40googlegroups.com
> 
> .
>
-- 
Adam

-- 
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/CAMyDDM2x4bYT1mAVmqj3HT9s8H2zZpO17JTMVMv7MEUfnXB3Mg%40mail.gmail.com.

Re: Improve migration conflict detection

[Dave Vernon]

If I had to guess, it would be that with more than one leaf node, you would 
end up a substantial challenge resolving dependancies which would create an 
Order(N) problem (i.e. there's a chance of excessive time to complete the 
resolution).

I certainly worked on some migration logic that took a similar approach to 
this.


On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
>
> I don’t think many people can answer this off the top of their heads. I 
> certainly can’t and I have contributed a couple things to migrations.
>
> It’s probably quite necessary there’s only one leaf node but I can’t say 
> for sure.
>
> On Thu, 13 Feb 2020 at 13:58, caio > 
> wrote:
>
>> Cool. If I'm understanding this correctly, it auto-resolves during 
>> *makemigrations*?
>>
>> I'm looking for something that could handle conflicts during the 
>> *migrate* command, but I'm not sure if that's really possible. I guess 
>> it depends on how intrinsic the single-leaf-node restriction is to the 
>> whole migration system
>>
>> Thanks!
>>
>> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye 
>> escreveu:
>>>
>>> Definitely a plus one on auto resolving migrations a test package still 
>>> in planning aims to solve this 
>>> https://github.com/jackton1/django-migration-resolver-hook
>>>
>>> On Feb 11, 2020, at 1:42 PM, Caio Ariede  wrote:
>>>
>>> Hey folks,
>>>
>>> I was looking at the code used to detect conflicts in migrations [1]. It 
>>> seems to use a very safe approach, by avoiding with multiple node leafs in 
>>> the migration graph.
>>>
>>> While this is safe, I’ve been having some problems when it comes to 
>>> scalability when having multiple migrations created in a short period of 
>>> time (for the same app).
>>>
>>> Questions:
>>>
>>> 1. Are there any obvious impediments on improving the conflicts 
>>> detection?
>>> 2. Does anyone have ideas on how to improve the conflict detection? (eg. 
>>> going down from app-level to model-level detection)
>>>
>>>
>>> Thanks!
>>>
>>>
>>> [1] 
>>> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>>>  
>>> 
>>>
>>> --
>>> Caio Ariede
>>> caio@gmail.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-d...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.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-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/31d78cfc-05bc-4bee-897b-3d9e2e502a3d%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
> Adam
>

-- 
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/bd688186-752b-4bf5-9340-5d9607d17038%40googlegroups.com.

Re: Relax system check on fields intermediary tables for db_table collision when database routers are installed

[Tim Graham]

The change for that ticket is already released. Please open a new ticket.

On Thursday, February 13, 2020 at 9:00:35 AM UTC-5, Anonymous Rabbit wrote:
>
> Before I move forward I just to want clarify, my changes are for the same 
> check specified in ticket #29092. Should I still open a new ticket in lieu 
> of re-opening #29092?
>
> On Thu, 13 Feb 2020 at 13:23, Adam Johnson > 
> wrote:
>
>> Please create a new ticket with a reference to the old one, and then a PR 
>> against that, since your change is for a different check.
>>
>> On Thu, 13 Feb 2020 at 12:15, Anonymous Rabbit > > wrote:
>>
>>> Hello there,
>>>
>>> This regards multi-database Django.
>>>
>>> On https://github.com/django/django/pull/11630, a change was made to 
>>> allow for multiple models with the same db_name, when a DATABASE_ROUTER is 
>>> present. 
>>> A ticket was open here for that issue: 
>>> https://groups.google.com/forum/#!searchin/django-updates/29092%7Csort:date/django-updates/K1VuUaa9BUc/IDmjZoiRCQAJ
>>>  . 
>>> Eventually it gets marked with wontfix, but with a notice: "Feel free to 
>>> reopen and offer a patch for evaluation if you think the implementation is 
>>> straightforward."
>>>
>>> I implemented the same changes of PR #11630, but with fields.E340 in 
>>> mind (fields.E340: The field’s intermediary table  clashes with 
>>> the table name of /..).
>>>
>>> I would like to open a PR for it, but I'm not sure of the process I have 
>>> to follow. Should the ticket be re-opened? Can I open the PR pointing at 
>>> the wontfix ticket instead? Should I open a new ticket for it?
>>>
>>> Best regards,
>>> Xavier
>>>
>>> -- 
>>> 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-d...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/7819a6e1-3f47-41c8-a6c0-d35de3f37578%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Adam
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/django-developers/Ypks34xj1AY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to 
>> django-d...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3-F2%3DBC4bGqiMpf2cG5F47Hn217DgV3YaVGc%2BK9_VWAg%40mail.gmail.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/2e38cc16-ac9c-461b-80f8-8fc3e21d6a53%40googlegroups.com.

Re: Relax system check on fields intermediary tables for db_table collision when database routers are installed

[Anonymous Rabbit]

Will do. Thanks.

On Thu, 13 Feb 2020 at 17:13, Tim Graham  wrote:

> The change for that ticket is already released. Please open a new ticket.
>
> On Thursday, February 13, 2020 at 9:00:35 AM UTC-5, Anonymous Rabbit wrote:
>>
>> Before I move forward I just to want clarify, my changes are for the same
>> check specified in ticket #29092. Should I still open a new ticket in lieu
>> of re-opening #29092?
>>
>> On Thu, 13 Feb 2020 at 13:23, Adam Johnson  wrote:
>>
>>> Please create a new ticket with a reference to the old one, and then a
>>> PR against that, since your change is for a different check.
>>>
>>> On Thu, 13 Feb 2020 at 12:15, Anonymous Rabbit  wrote:
>>>
 Hello there,

 This regards multi-database Django.

 On https://github.com/django/django/pull/11630, a change was made to
 allow for multiple models with the same db_name, when a DATABASE_ROUTER is
 present.
 A ticket was open here for that issue:
 https://groups.google.com/forum/#!searchin/django-updates/29092%7Csort:date/django-updates/K1VuUaa9BUc/IDmjZoiRCQAJ
  .
 Eventually it gets marked with wontfix, but with a notice: "Feel free to
 reopen and offer a patch for evaluation if you think the implementation is
 straightforward."

 I implemented the same changes of PR #11630, but with fields.E340 in
 mind (fields.E340: The field’s intermediary table  clashes with
 the table name of /..).

 I would like to open a PR for it, but I'm not sure of the process I
 have to follow. Should the ticket be re-opened? Can I open the PR pointing
 at the wontfix ticket instead? Should I open a new ticket for it?

 Best regards,
 Xavier

 --
 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-d...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/7819a6e1-3f47-41c8-a6c0-d35de3f37578%40googlegroups.com
 
 .

>>>
>>>
>>> --
>>> Adam
>>>
>>> --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/django-developers/Ypks34xj1AY/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> django-d...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CAMyDDM3-F2%3DBC4bGqiMpf2cG5F47Hn217DgV3YaVGc%2BK9_VWAg%40mail.gmail.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/Ypks34xj1AY/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/2e38cc16-ac9c-461b-80f8-8fc3e21d6a53%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/CADfb6NLuVsV%3DUXOVYjYt9GvFo5jo%2B_EZWaPwLFDRVP1yviqNyw%40mail.gmail.com.