Re: FK constraints are not checked at the end of nested atomic blocks

[Shai Berger]

On Thursday 31 December 2015 06:31:40 Gavin Wahl wrote:
> I understand that a database is invalid or invalid as a whole, which is why
> you don't need to check constraints until transaction commit (when the
> transaction becomes visible to the world). Why do you want to bundle
> constraint checking with a savepoint release though? They seem logically
> unrelated. Wouldn't a standalone way to check deferred constraints be more
> useful?
> 
It makes some sense to check constraints at the end of a set of operations 
which are defined as a unit of work. 

At the database level, it is mandatory at a transaction's end, and makes more 
sense at a savepoint release than at an arbitrary point in the transaction 
(although it does make sense elsewhere).

At Python code level, we use the same construct (atomic() block) for 
transactions and savepoints, so it would make sense to allow them to behave in 
similar ways. It is also arguable that any place where you'd want to check 
constraints signifies the end of a unit of work, and so we should encourage the 
uise of atomic() to also specify the beginning of said unit.

And then, there's "there should be one obvious way to do it", which hints we 
should avoid having both check-in-atomic and check-independently.

My 2 cents,
Shai.

Re: FK constraints are not checked at the end of nested atomic blocks

[Gavin Wahl]

I understand that a database is invalid or invalid as a whole, which is why
you don't need to check constraints until transaction commit (when the
transaction becomes visible to the world). Why do you want to bundle
constraint checking with a savepoint release though? They seem logically
unrelated. Wouldn't a standalone way to check deferred constraints be more
useful?

On Wed, Dec 30, 2015 at 4:23 PM, Shai Berger  wrote:

> Hi,
>
> On Tuesday 29 December 2015 19:40:44 Gavin Wahl wrote:
> > What does it even mean for constraints to be checked at savepoint
> commit? I
> > would expect this to not cause any errors:
> >
> > with atomic():
> > # insert invalid fk
> > with atomic(check_deferred_constraints=True):
> > # do stuff that doesn't invalidate any contraints
> > # delete the invalid fk inserted before
> >
>
> I think your expectation is wrong, for both technical and "ideological"
> reasons.
>
> Technically, you can easily do things in the inner block which, although
> they
> do not violate any constraints in themselves, rely on the invalid FK
> record.
> If that were allowed to pass silently, we would violate the expectation
> that
> "if the inner block succeeded, then things in it are ok".
>
> Philosophically, I don't think "checking the constraints only for things I
> changed here" is a valid *logical* operation, as you seem to imply; a
> database
> is valid or broken as a whole. The fact that we can get away with checking
> only the changes at a transaction limit is an *implementation* shortcut,
> valid
> only as far as it is logically equivalent to checking the whole database.
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACPudh1WTvBi_m%3DJZ%2BZvbWpj-pXu5T%2BpyjEwF%3D5_34pVV-17eA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Florian Apolloner]

You are free to use what your PaaS provider supplies, but if you are using 
heroku (and many others) you do not have a choice. If AWS allows you to use 
apache 2.4 in event mode, then by all means use it! But there are plenty of 
platforms out there where you cannot easily serve static files and/or 
performance does not matter too much. So in the end it boils down if we can 
remove code from Django, if yes it is a win, even if it is just used for 
the development server.

On Thursday, December 31, 2015 at 1:00:13 AM UTC+1, Cristiano Coelho wrote:
>
> Just curious, about PaaS, I know AWS (Amazon) deploys python/django on 
> apache (which is quite decent), and apache also serves static files 
> decently. What would be wrong with this?
> The idea of having Python serving static files (and potentially gziping 
> it), when python is one of the slowest languages out there, I don't think 
> it is really a good idea. You should be really serving static files with 
> something implemented in C/C++ or similar high performant language (read 
> nginx or apache). How wrong am I?
>
> El viernes, 5 de diciembre de 2014, 5:19:45 (UTC-3), Aymeric Augustin 
> escribió:
>>
>> Yes, I support this plan.
>>
>> "Serve your files with nginx!" doesn't fly in the age of PaaS.
>>
>> Serving static files with Django and having a CDN cache them is a 
>> reasonable setup as far as I know.
>>
>> I don't know if the "probably insecure" argument still holds. Are there 
>> some specific security risks in serving files that don't exist in serving 
>> dynamic content? I'd say dynamic content is more difficult. This main 
>> problem I can imagine when serving files is directory traversal. We already 
>> have protections against this class of attacks in several features. (Usual 
>> disclaimer: my background is security is mostly theoretical.)
>>
>> -- 
>> Aymeric.
>>
>>
>> 2014-12-05 6:33 GMT+01:00 Collin Anderson :
>>
>>> Hi All,
>>>
>>> I'm pretty interested in getting secure and _somewhat_ efficient static 
>>> file serving in Django.
>>>
>>> Quick history:
>>> 2005 - Jacob commits #428: a "static pages" view.  Note that this view 
>>> should only be used for testing!"
>>> 2010 - Jannis adds staticfiles. Serving via django is considered "
>>> grossly inefficient and probably insecure".
>>> 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn.
>>> 2012 - Aymeric adds StreamingHttpResponse and now files are read in 
>>> chunks rather than reading the entire file into memory. (No longer grossly 
>>> inefficient IMHO.)
>>>
>>> I propose:
>>> - Deprecate the "show_indexes" parameter of static.serve() (unless 
>>> people actually use it).
>>> - Have people report security issues to secu...@djangoproject.com (like 
>>> always)
>>> - Audit the code and possibly add more security checks and tests.
>>> - add wsgi.file_wrapper support to responses (5-line proof of concept: 
>>> https://github.com/django/django/pull/3650 )
>>> - support serving static files in production, but still recommend 
>>> nginx/apache or a cdn for performance.
>>> - make serving static files in production an opt-in, but put the view in 
>>> project_template/project_name/urls.py
>>>
>>> I think it's a huge win for low-traffic sites or sites in the "just 
>>> trying to deploy and get something live" phase. You can always optimize 
>>> later by serving via nginx or cdn.
>>> We already have the views, api, and logic around for finding and serving 
>>> the correct files.
>>> We can be just as efficient and secure as static/dj-static without 
>>> needing to make people install and configure wsgi middleware to the 
>>> application.
>>> We could have staticfiles classes implement more complicated features 
>>> like giving cache recommendations, and serving pre-gzipped files.
>>>
>>> Is this a good idea? I realize it's not totally thought through. I'm 
>>> fine with waiting until 1.9 if needed.
>>>
>>> Collin
>>>
>>> On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote:

 Hi All,

 I think doing something here is really good idea. I'm happy with any of 
 the solutions mentioned so far.

 My question is: what does static/dj-static do that our built-in code 
 doesn't do? What makes it more secure? It seems to me we're only missing 
 is 
 wsgi.file_wrapper and maybe a few more security checks. Why don't we just 
 make our own code secure and start supporting it?
 Here's basic wsgi.file_wrapper support: https://github.com/django/
 django/pull/3650

 We could then, over time, start supporting more extensions ourselves: 
 ranges, pre-gziped files, urls with never-changing content, etc. That way 
 we get very, very deep django integration. It seems to me this is a piece 
 that a web framework should be able to support itself.

 Collin


 On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote:
>
> Berker has worked on integrating gunicorn with 

Re: delegating our static file serving

[Cristiano Coelho]

Just curious, about PaaS, I know AWS (Amazon) deploys python/django on 
apache (which is quite decent), and apache also serves static files 
decently. What would be wrong with this?
The idea of having Python serving static files (and potentially gziping 
it), when python is one of the slowest languages out there, I don't think 
it is really a good idea. You should be really serving static files with 
something implemented in C/C++ or similar high performant language (read 
nginx or apache). How wrong am I?

El viernes, 5 de diciembre de 2014, 5:19:45 (UTC-3), Aymeric Augustin 
escribió:
>
> Yes, I support this plan.
>
> "Serve your files with nginx!" doesn't fly in the age of PaaS.
>
> Serving static files with Django and having a CDN cache them is a 
> reasonable setup as far as I know.
>
> I don't know if the "probably insecure" argument still holds. Are there 
> some specific security risks in serving files that don't exist in serving 
> dynamic content? I'd say dynamic content is more difficult. This main 
> problem I can imagine when serving files is directory traversal. We already 
> have protections against this class of attacks in several features. (Usual 
> disclaimer: my background is security is mostly theoretical.)
>
> -- 
> Aymeric.
>
>
> 2014-12-05 6:33 GMT+01:00 Collin Anderson  >:
>
>> Hi All,
>>
>> I'm pretty interested in getting secure and _somewhat_ efficient static 
>> file serving in Django.
>>
>> Quick history:
>> 2005 - Jacob commits #428: a "static pages" view.  Note that this view 
>> should only be used for testing!"
>> 2010 - Jannis adds staticfiles. Serving via django is considered "grossly 
>> inefficient and probably insecure".
>> 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn.
>> 2012 - Aymeric adds StreamingHttpResponse and now files are read in 
>> chunks rather than reading the entire file into memory. (No longer grossly 
>> inefficient IMHO.)
>>
>> I propose:
>> - Deprecate the "show_indexes" parameter of static.serve() (unless people 
>> actually use it).
>> - Have people report security issues to secu...@djangoproject.com 
>>  (like always)
>> - Audit the code and possibly add more security checks and tests.
>> - add wsgi.file_wrapper support to responses (5-line proof of concept: 
>> https://github.com/django/django/pull/3650 )
>> - support serving static files in production, but still recommend 
>> nginx/apache or a cdn for performance.
>> - make serving static files in production an opt-in, but put the view in 
>> project_template/project_name/urls.py
>>
>> I think it's a huge win for low-traffic sites or sites in the "just 
>> trying to deploy and get something live" phase. You can always optimize 
>> later by serving via nginx or cdn.
>> We already have the views, api, and logic around for finding and serving 
>> the correct files.
>> We can be just as efficient and secure as static/dj-static without 
>> needing to make people install and configure wsgi middleware to the 
>> application.
>> We could have staticfiles classes implement more complicated features 
>> like giving cache recommendations, and serving pre-gzipped files.
>>
>> Is this a good idea? I realize it's not totally thought through. I'm fine 
>> with waiting until 1.9 if needed.
>>
>> Collin
>>
>> On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> I think doing something here is really good idea. I'm happy with any of 
>>> the solutions mentioned so far.
>>>
>>> My question is: what does static/dj-static do that our built-in code 
>>> doesn't do? What makes it more secure? It seems to me we're only missing is 
>>> wsgi.file_wrapper and maybe a few more security checks. Why don't we just 
>>> make our own code secure and start supporting it?
>>> Here's basic wsgi.file_wrapper support: https://github.com/django/
>>> django/pull/3650
>>>
>>> We could then, over time, start supporting more extensions ourselves: 
>>> ranges, pre-gziped files, urls with never-changing content, etc. That way 
>>> we get very, very deep django integration. It seems to me this is a piece 
>>> that a web framework should be able to support itself.
>>>
>>> Collin
>>>
>>>
>>> On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote:

 Berker has worked on integrating gunicorn with runserver 
  so that we might be able 
 to deprecate our own homegrown webserver. Windows support for gunicorn is 
 supposedly coming soon 
 which 
 may actually make the idea feasible. This way we provide a more secure 
 solution out of the box (anecdotes indicate that runserver is widely used 
 in production despite our documentation warnings against doing so).

 On the pull request, Anssi had an idea to use dj-static 
  to serve static/media 
 files. My understanding is that we 

Re: delegating our static file serving

[Chris Cogdon]

Also consider the media files could number into the millions (or 
bajizillions?). Particularly for, say, a image hosting application. Clearly 
it would not be feasible to enumerate all the files, and there would 
clearly be regular additions. It might be that this use case is simply 
"beyond the scope" of a django-supplied static files server, and the 
developer should instead use nginx, lighttpd or something similar.

On Tuesday, December 29, 2015 at 9:31:02 AM UTC-8, David Evans wrote:
>
> 2. Serving media files is a slightly different case. WhiteNoise was 
> designed around the assumption that it's serving a set of 
> developer-supplied, public files which remain unchanged during the lifetime 
> of the process. This simplifies a lot of performance and security concerns 
> that come with serving mutable, user-supplied files. At present, if you use 
> `add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)` as you 
> suggested then WhiteNoise won't pick up any files that were uploaded after 
> the application was started -- at least, not unless you enable the 
> "autorefresh" setting which I explicitly don't recommend for production.
>

-- 
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/d489de11-018a-40e0-8419-40b4d18de9a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Chris Cogdon]

Also consider the media files could number into the millions (or 
bajizillions?). Particularly for, say, a image hosting application. Clearly 
it would not be feasible to enumerate all the files, and there would 
clearly be regular additions. It might be that this use case is simply 
"beyond the scope" of a django-supplied static files server, and the 
developer should instead use nginx, lighttpd or something similar.


On Tuesday, December 29, 2015 at 9:31:02 AM UTC-8, David Evans wrote:
>
> 2. Serving media files is a slightly different case. WhiteNoise was 
> designed around the assumption that it's serving a set of 
> developer-supplied, public files which remain unchanged during the lifetime 
> of the process. This simplifies a lot of performance and security concerns 
> that come with serving mutable, user-supplied files. At present, if you use 
> `add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)` as you 
> suggested then WhiteNoise won't pick up any files that were uploaded after 
> the application was started -- at least, not unless you enable the 
> "autorefresh" setting which I explicitly don't recommend for production.
>
> Obviously it's possible to support this if we decide this is an important 
> goal but it will need more thought and will definitely be more work than 
> just supporting static files.
>
> On Tuesday, 29 December 2015 00:36:06 UTC, Tim Graham wrote:
>>
>> I'd like to work together with Dave to develop a proof of concept that 
>> integrates whitenoise into Django. I spent about an hour looking through 
>> whitenoise and our own static file serving code, and I think integrating 
>> whitenoise will yield a simpler user experience with about the same amount 
>> of code as have now.
>>
>> Essentially, we'd recommend adding something like this to existing 
>> wsgi.py files (it would be in the default startproject template)
>>
>> from whitenoise.django import DjangoWhiteNoise
>> application = DjangoWhiteNoise(application)
>> application.add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)
>>
>> which would have the benefit of working out of the box in production too, 
>> I think. Of course, you could disable that based on settings.DEBUG or some 
>> other toggle.
>>
>> We could then deprecate:
>>
>> * django/contrib/staticfiles/views.py
>> * django/contrib/staticfiles/management/commands/runserver.py
>> * django/contrib/staticfiles/handlers.py
>> * django/views/static.py
>>
>> Any objections to doing further investigation in this area?
>>
>> On Saturday, June 20, 2015 at 8:09:11 AM UTC-4, David Evans wrote:
>>>
>>> On Friday, 5 December 2014 19:14:29 UTC, Carl Meyer wrote:

 On 12/04/2014 10:33 PM, Collin Anderson wrote: 
 > Hi All, 
 > 
 > I'm pretty interested in getting secure and _somewhat_ efficient 
 static 
 > file serving in Django. 
 > 
 > Quick history: 
 > 2005 - Jacob commits #428: a "static pages" view.  Note that this 
 view 
 > should only be used for testing!" 
 > 2010 - Jannis adds staticfiles. Serving via django is considered 
 "grossly 
 > inefficient and probably insecure". 
 > 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn. 
 > 2012 - Aymeric adds StreamingHttpResponse and now files are read in 
 chunks 
 > rather than reading the entire file into memory. (No longer grossly 
 > inefficient IMHO.) 
 > 
 > I propose: 
 > - Deprecate the "show_indexes" parameter of static.serve() (unless 
 people 
 > actually use it). 
 > - Have people report security issues to secu...@djangoproject.com 
 (like 
 > always) 
 > - Audit the code and possibly add more security checks and tests. 
 > - add wsgi.file_wrapper support to responses (5-line proof of 
 concept: 
 > https://github.com/django/django/pull/3650 ) 
 > - support serving static files in production, but still recommend 
 > nginx/apache or a cdn for performance. 
 > - make serving static files in production an opt-in, but put the view 
 in 
 > project_template/project_name/urls.py 
 > 
 > I think it's a huge win for low-traffic sites or sites in the "just 
 trying 
 > to deploy and get something live" phase. You can always optimize 
 later by 
 > serving via nginx or cdn. 
 > We already have the views, api, and logic around for finding and 
 serving 
 > the correct files. 
 > We can be just as efficient and secure as static/dj-static without 
 needing 
 > to make people install and configure wsgi middleware to the 
 application. 
 > We could have staticfiles classes implement more complicated features 
 like 
 > giving cache recommendations, and serving pre-gzipped files. 
 > 
 > Is this a good idea? I realize it's not totally thought through. I'm 
 fine 
 > with waiting until 1.9 if needed. 

 I also think this is a good plan. It certainly makes sense to look at 

Re: admin: implementing list_prefetch_related

[Marc Tamlyn]

Hi Richard,

Overriding the queryset is a pretty simple method override, I'm not sure
there is sufficient need for prefetching here. In particular, the syntax
for prefetch related is much more complex than for select related, so it's
less well suited to this kind of shortcut.

Marc
On 30 Dec 2015 10:26 a.m., "Riccardo Magliocchetti" <
riccardo.magliocche...@gmail.com> wrote:

> Hello,
>
> the need to list an m2m relationship serialized in the admin list view
> happens quite often to me and overriding the queryset may not be as trivial
> as a ModelAdmin attribute. It makes sense to me to match what is possible
> with foreign keys and list_select_related.
> Any opinion on implementing list_prefetch_related for ModelAdmin?
>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.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/5683B12D.6000600%40gmail.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 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/CAMwjO1ECoZGJEkGttZtAZeSBUktHRoYCX_hOj-1ehYtGCRSLzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FK constraints are not checked at the end of nested atomic blocks

[Shai Berger]

Hi,

On Tuesday 29 December 2015 19:40:44 Gavin Wahl wrote:
> What does it even mean for constraints to be checked at savepoint commit? I
> would expect this to not cause any errors:
> 
> with atomic():
> # insert invalid fk
> with atomic(check_deferred_constraints=True):
> # do stuff that doesn't invalidate any contraints
> # delete the invalid fk inserted before
> 

I think your expectation is wrong, for both technical and "ideological" 
reasons. 

Technically, you can easily do things in the inner block which, although they 
do not violate any constraints in themselves, rely on the invalid FK record. 
If that were allowed to pass silently, we would violate the expectation that 
"if the inner block succeeded, then things in it are ok".

Philosophically, I don't think "checking the constraints only for things I 
changed here" is a valid *logical* operation, as you seem to imply; a database 
is valid or broken as a whole. The fact that we can get away with checking 
only the changes at a transaction limit is an *implementation* shortcut, valid 
only as far as it is logically equivalent to checking the whole database.

Shai.

Re: Working with Django signals

[Tim Graham]

Please write to django-users as this mailing list is for the development of 
Django itself.

On Wednesday, December 30, 2015 at 5:28:22 PM UTC-5, Bernardo Garcia wrote:
>
> Hi Django developers community
> A great greetings
>
> I want share with you the following question:
>
> I have a custom users schema in Django for work with roles or users type, 
> creating an application named userprofile which will be or will setup my 
> custom user model.
>
>
> In my settings.py I have the following configuration:
>
>
> INSTALLED_APPS = [
> ...
> 'userprofile',]#Custom model Users
> AUTH_USER_MODEL = 'userprofile.User'
>
>
> I customize my User class (userprofile/models.py) that inherit of the 
> AbstractUser class for add some fields to my User model due to my 
> requirements demanded me.
>
>
> I also create these another models for roles/profile users (MedicalProfile, 
> PatientProfile, PhysiotherapistProfile) with their own fields or 
> attributes
>
>
> In addition MedicalProfile, PatientProfile, PhysiotherapistProfile have a 
> OneToOneField relationship with my custom model/class User
>
>
> All this I want denote in this figure userprofile/models.py
>
>
>
> 
>
>
>
> *My Question*
>
>
> I want to focus my question in relation about of the post_save signal 
> operation, this mean in the create_profile_for_new_user() method:
>
>
> @receiver(post_save, sender=settings.AUTH_USER_MODEL)def 
> create_profile_for_new_user(sender, instance, created, **kwargs):
> user = instance
> # - Begin debug--
> import ipdb
> #
> if created:
> if user.is_medical:
> ipdb.set_trace()
> profile=MedicalProfile(user=instance)
> profile.save()
>
>
> I want, each that an user is created, automatically (by post_save signal 
> action) be created their profile (MedicalProfile, PatientProfile, 
> PhysiotherapistProfile) according to if their field checked (is_medical, 
> is_patient, is_physiotherapist) at the User class 
> 
>  (same 
> black image presented above)
>
>
> The inconvenient that I have is with my signal, and it's the following:
>
>- When I create an user via django admin, indicating that this user is 
>medical (have the is_medical field/attribute checked in the user admin 
>form) in my MedicalProfile model, their profile instance not is saved or 
>don't created
>
> I have been checking the situation through ipdb basic debug functions and 
>
> I think so that when I create the user the compiler or the steps don't 
> arrive to 
>
> the section when I check if my user is medical (if user.is_medical code 
> line) 
>
> such as follow:
>
>
> 1. I've placed a debug point initially of this way:
>
>
> 
>
>
>
>
>
>1. I create a user via django admin 
>
> I go to my Django admin and I create a new user and when press click in 
> "Save" (first moment to user create): 
>
> 
>
>
>
>
> *3. When I press "Save" button, the debug point enter to action*
>
>
> Then, I check the value of the variables that accord to my function which 
> I am applying the signal are defined until the moment and they are inside 
> the debug process. They are:
>
>- sender, created, instance (this mean, the parameters of the function)
>- user, that is the same instance variable
>
> 
>
>
>
> The above, denote that the parameters are arriving. All is O.K for the 
> moment.
>
>1. *4. Then, I perform the debug a few more below in the code (red 
>square in the following figure) and I analyze the following:*
>
> 
>
>
>
>
> It's true the sender, instance and created parameters are arriving and 
> when check for the is_medical attribute (boolean) which depend that the 
> profile be saved in MedicalProfile model, I get this:
>
>
> 
>
>
>
> My attribute is_medical have the boolean value as False and I think that 
> I can understand it,
>
> because we know that the user creation is divided in two sequentials 
> phases in the django admin
>
>
>
>- The first phase when I allocate username and password
>
> 
>
>
>
>
>- And the second phase when I enter the other fields or attributes in 
>the creation of the that same user.
>
>
> 
>
>
>
>
> I think that when the user is saved in the first phase (I allocate only 
> username and password) the is_medical checkbox not yet is setup (checked) 
> and this is the reason by which their value is False
>
> It's right?
>
>1. *5*. If I placed a few more below the set_trace() point debug such 
>as 

Re: Adding name to fieldsets to improve their validation error text

[Tim Graham]

Hi Ben,

>From a quick look, I'd suggest trying an approach similar to how form 
fields work, with a `default_error_messages` class attribute which can be 
override by an `error_messages` parameter provided to __init__().

Tim

On Thursday, December 17, 2015 at 5:46:04 PM UTC-5, Benjamin W Stookey 
wrote:
>
> Right now, if min or max validation doesn't pass on a fieldset, we provide 
> something 
> like the following error 
> 
> :
>
> Please submit 1 or more forms.
>
>
> I'd like to propose that we provide a way to generate a slightly more 
> specific error. For example:
>
> Please submit 1 or more authors.
>
>
> I'm eager to write the code to do this. There are a number of ways to 
> implement it so I figured it would need discussion first and a ticket 
> before I could issue a pull request. If people think this is a good idea, 
> I'll document a few potential approaches for discussion.
>
> A few options that come to mind before diving in.
>
>- Adding a `verbose_name_plural` property to the formset
>- Pulling the `verbose_name_plural` from the form class (if forms are 
>model forms)
>
> Thanks,
> -Ben
>

-- 
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/36c0651c-ee0b-40fb-9c8d-42ccbdbcb90d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Working with Django signals

[Bernardo Garcia]

Hi Django developers community
A great greetings

I want share with you the following question:

I have a custom users schema in Django for work with roles or users type, 
creating an application named userprofile which will be or will setup my 
custom user model.


In my settings.py I have the following configuration:


INSTALLED_APPS = [
...
'userprofile',]#Custom model Users
AUTH_USER_MODEL = 'userprofile.User'


I customize my User class (userprofile/models.py) that inherit of the 
AbstractUser class for add some fields to my User model due to my 
requirements demanded me.


I also create these another models for roles/profile users (MedicalProfile, 
PatientProfile, PhysiotherapistProfile) with their own fields or attributes


In addition MedicalProfile, PatientProfile, PhysiotherapistProfile have a 
OneToOneField relationship with my custom model/class User


All this I want denote in this figure userprofile/models.py






*My Question*


I want to focus my question in relation about of the post_save signal 
operation, this mean in the create_profile_for_new_user() method:


@receiver(post_save, sender=settings.AUTH_USER_MODEL)def 
create_profile_for_new_user(sender, instance, created, **kwargs):
user = instance
# - Begin debug--
import ipdb
#
if created:
if user.is_medical:
ipdb.set_trace()
profile=MedicalProfile(user=instance)
profile.save()


I want, each that an user is created, automatically (by post_save signal 
action) be created their profile (MedicalProfile, PatientProfile, 
PhysiotherapistProfile) according to if their field checked (is_medical, 
is_patient, is_physiotherapist) at the User class 

 (same 
black image presented above)


The inconvenient that I have is with my signal, and it's the following:

   - When I create an user via django admin, indicating that this user is 
   medical (have the is_medical field/attribute checked in the user admin 
   form) in my MedicalProfile model, their profile instance not is saved or 
   don't created

I have been checking the situation through ipdb basic debug functions and 

I think so that when I create the user the compiler or the steps don't 
arrive to 

the section when I check if my user is medical (if user.is_medical code 
line) 

such as follow:


1. I've placed a debug point initially of this way:








   1. I create a user via django admin 

I go to my Django admin and I create a new user and when press click in 
"Save" (first moment to user create): 






*3. When I press "Save" button, the debug point enter to action*


Then, I check the value of the variables that accord to my function which I 
am applying the signal are defined until the moment and they are inside the 
debug process. They are:

   - sender, created, instance (this mean, the parameters of the function)
   - user, that is the same instance variable





The above, denote that the parameters are arriving. All is O.K for the 
moment.

   1. *4. Then, I perform the debug a few more below in the code (red 
   square in the following figure) and I analyze the following:*






It's true the sender, instance and created parameters are arriving and when 
check for the is_medical attribute (boolean) which depend that the profile 
be saved in MedicalProfile model, I get this:






My attribute is_medical have the boolean value as False and I think that I 
can understand it,

because we know that the user creation is divided in two sequentials phases 
in the django admin



   - The first phase when I allocate username and password
   





   - And the second phase when I enter the other fields or attributes in 
   the creation of the that same user.
   






I think that when the user is saved in the first phase (I allocate only 
username and password) the is_medical checkbox not yet is setup (checked) 
and this is the reason by which their value is False

It's right?

   1. *5*. If I placed a few more below the set_trace() point debug such as 
   follow in the figure (red square):




In this point, ipdb do not enter in action, my debug is not reached or does 
not work.

The signal action that is doing is create the new User, but not create the 
profile for the user, in this case, the MedicalProfile beacuse I checked 
the is_medical checkbox when I was create the user. Just create the user 
and nothing more ...

I think that the is_medical 

Re: Backwards-compatibility import shims

[Michael Manfre]

On Wed, Dec 30, 2015 at 11:52 AM, Tim Graham  wrote:

> For that reason, I think we should reconsider making Django's deprecation
> warnings loud by default (at least in LTS versions) [1]. Otherwise, users
> will pester library authors to fix those warnings and we haven't really
> made things easier.
>
> Instead, the idea would be for library authors to continue using the
> deprecated APIs while supporting the LTS in which they are deprecated and
> the previous LTS. When the version of Django following the LTS is released,
> library authors can then drop support for all Django versions before the
> LTS, check their package with the LTS using python -Wall and make the
> deprecation warning fixes, then seamlessly add support for the next version
> of Django.
>
> Does that make sense?
>

This makes sense to me. +1

Regards,
Michael Manfre

-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/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/CAGdCwBtcyujD7iLV30o%2BBGUHOc-rvWqgq3TZ3CjDX4CYo4q7xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Revisiting multiline tags

[Flimm]

+1 from me. blocktrans is really ugly if it has to fit in one line.

On Saturday, February 18, 2012 at 7:04:33 AM UTC+1, Glenn Washburn wrote:
>
> Hello django devers,
>
> I'd like to reopen discussion on the multiline tag issue (see:
> https://code.djangoproject.com/ticket/8652) which was closed 3 three
> years ago as "won't fix".  The last comment notes that this won't
> happen as the decision has been made many times.  But there is no link
> to any discussion on this topic, so I can only assume mtredinnick's
> point two is the supposed reason for not fixing this.
>
> I've done rudimentary testing on a 6 character change in 1.3.1 to
> template.base.tags_re (add the re.S flag to the regex), which appears
> to solve the issue.  So I don't see all the work which was being
> referred to in mtredinnick's point two.  Perhaps the template engine
> has been rewritten since then.  The only test that fails after making
> this change (in 1.3.1) is the one that explicitly tests that tgs should
> not be multiline.
>
> Since this change appears to be so low impact and such a simple
> change.  Are there any reasons why this change shouldn't be included in
> django?  Maybe I'm missing something.
>
> Its interesting to note that
> https://code.djangoproject.com/ticket/3888, which is referenced in the
> issue, is also closed as "won't fix", but appears to be allowed in
> 1.3.1.  So there is a precedent for "won't fix" issues being included.
>
> -Glenn
>
>

-- 
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/06f69eec-5eac-4a1d-bed3-bf3bbd25a62f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backwards-compatibility import shims

[Tim Graham]

Given that alternate, I guess I'm not really enthusiastic about making our 
deprecation policy more complicated. While urlresolvers is a commonly used 
module, updating should be a simple find and replace for the imports.

On the other hand, I thought of a slight flaw in our current deprecation 
scheme. If a third-party library wants to support both 1.8 and 1.11 (next 
LTS) would have to use a try (new import)/except (old import) pattern to 
avoid code running on 1.11 from raising deprecation warnings (some pending 
deprecation in 1.10, deprecated in 1.11, and removed in 2.0). In my mind, 
part of the purpose of the new policy was to avoid this type of complexity.

For that reason, I think we should reconsider making Django's deprecation 
warnings loud by default (at least in LTS versions) [1]. Otherwise, users 
will pester library authors to fix those warnings and we haven't really 
made things easier.

Instead, the idea would be for library authors to continue using the 
deprecated APIs while supporting the LTS in which they are deprecated and 
the previous LTS. When the version of Django following the LTS is released, 
library authors can then drop support for all Django versions before the 
LTS, check their package with the LTS using python -Wall and make the 
deprecation warning fixes, then seamlessly add support for the next version 
of Django.

Does that make sense?

[1] slightly related: https://code.djangoproject.com/ticket/25999 

On Wednesday, December 30, 2015 at 10:28:02 AM UTC-5, Marten Kenbeek wrote:
>
> One solution is to create a RemovedInFutureVersionWarning to allow 
> projects to catch the change when running with -Wall, without committing 
> to a specific release. 
>
> On Wednesday, December 30, 2015 at 3:05:32 PM UTC+1, Tim Graham wrote:
>>
>> To save a link click, the question is about moving 
>> django.core.urlresolvers to django.urls and whether or not to start the 
>> deprecating of django.core.urlresolvers immediately.
>>
>> I don't have a strong opinion myself. On one hand, delaying gives 
>> projects more time to update, on the other, I suspect many projects will 
>> continue using django.core.urlresolvers in new code if there's no 
>> indication that it's deprecated.
>>
>> On Wednesday, December 30, 2015 at 8:50:10 AM UTC-5, Marten Kenbeek wrote:
>>>
>>> As noted 
>>> by 
>>> Collin on deprecating old import paths:
>>>
>>> I personally wouldn't mind if we didn't actually deprecate this, and 
 left these shims in a bit longer :). (Makes it just a hair easier for 
 people upgrading.) But that's just me.
>>>
>>>
>>> There is very little maintenance overhead to keep backwards-compatible 
>>> import shims longer than the current deprecation cycle.
>>>
>>> Any thoughts on this?
>>>
>>

-- 
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/fbc27057-331f-4d7e-b411-a656f75cd7d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backwards-compatibility import shims

[Marten Kenbeek]

One solution is to create a RemovedInFutureVersionWarning to allow projects 
to catch the change when running with -Wall, without committing to a 
specific release. 

On Wednesday, December 30, 2015 at 3:05:32 PM UTC+1, Tim Graham wrote:
>
> To save a link click, the question is about moving 
> django.core.urlresolvers to django.urls and whether or not to start the 
> deprecating of django.core.urlresolvers immediately.
>
> I don't have a strong opinion myself. On one hand, delaying gives projects 
> more time to update, on the other, I suspect many projects will continue 
> using django.core.urlresolvers in new code if there's no indication that 
> it's deprecated.
>
> On Wednesday, December 30, 2015 at 8:50:10 AM UTC-5, Marten Kenbeek wrote:
>>
>> As noted 
>> by 
>> Collin on deprecating old import paths:
>>
>> I personally wouldn't mind if we didn't actually deprecate this, and left 
>>> these shims in a bit longer :). (Makes it just a hair easier for people 
>>> upgrading.) But that's just me.
>>
>>
>> There is very little maintenance overhead to keep backwards-compatible 
>> import shims longer than the current deprecation cycle.
>>
>> Any thoughts on this?
>>
>

-- 
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/4a0e4865-b4b4-4aaf-af91-2cdc77965839%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Backwards-compatibility import shims

[Tim Graham]

To save a link click, the question is about moving django.core.urlresolvers 
to django.urls and whether or not to start the deprecating of 
django.core.urlresolvers immediately.

I don't have a strong opinion myself. On one hand, delaying gives projects 
more time to update, on the other, I suspect many projects will continue 
using django.core.urlresolvers in new code if there's no indication that 
it's deprecated.

On Wednesday, December 30, 2015 at 8:50:10 AM UTC-5, Marten Kenbeek wrote:
>
> As noted by 
> Collin on deprecating old import paths:
>
> I personally wouldn't mind if we didn't actually deprecate this, and left 
>> these shims in a bit longer :). (Makes it just a hair easier for people 
>> upgrading.) But that's just me.
>
>
> There is very little maintenance overhead to keep backwards-compatible 
> import shims longer than the current deprecation cycle.
>
> Any thoughts on this?
>

-- 
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/44b06bd1-49a1-4855-b282-98c954b91d5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed with the MySQL max index length problem for Django 1.10

[Collin Anderson]

I think mysql used to just give a warning and maybe now it's an error? It
can currently be reproduced with just a blank project (using django master,
mysql 5.5.46-0ubuntu0.14.04.2):

mysql -e'create database mb4test charset utf8mb4'
django-admin startproject mb4test
cd mb4test
vi mb4test/settings.py  # set up db settings
./manage.py migrate

Operations to perform:
  Apply all migrations: auth, admin, sessions, contenttypes
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length...Traceback (most
recent call last):
  File "/home/collin/django1.10/django/db/backends/utils.py", line 64, in
execute
return self.cursor.execute(sql, params)
  File "/home/collin/django1.10/django/db/backends/mysql/base.py", line
112, in execute
return self.cursor.execute(query, args)
  File
"/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line
226, in execute
self.errorhandler(self, exc, value)
  File
"/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/connections.py",
line 36, in defaulterrorhandler
raise errorvalue
  File
"/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line
217, in execute
res = self._query(query)
  File
"/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line
378, in _query
rowcount = self._do_query(q)
  File
"/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/cursors.py", line
341, in _do_query
db.query(q)
  File
"/home/collin/mb4test/lib/python3.4/site-packages/MySQLdb/connections.py",
line 280, in query
_mysql.connection.query(self, query)
_mysql_exceptions.OperationalError: (1071, 'Specified key was too long; max
key length is 767 bytes')

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "./manage.py", line 10, in 
execute_from_command_line(sys.argv)
  File "/home/collin/django1.10/django/core/management/__init__.py", line
349, in execute_from_command_line
utility.execute()
  File "/home/collin/django1.10/django/core/management/__init__.py", line
341, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/collin/django1.10/django/core/management/base.py", line 290,
in run_from_argv
self.execute(*args, **cmd_options)
  File "/home/collin/django1.10/django/core/management/base.py", line 339,
in execute
output = self.handle(*args, **options)
  File
"/home/collin/django1.10/django/core/management/commands/migrate.py", line
177, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
  File "/home/collin/django1.10/django/db/migrations/executor.py", line 92,
in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake,
fake_initial=fake_initial)
  File "/home/collin/django1.10/django/db/migrations/executor.py", line
121, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake,
fake_initial=fake_initial)
  File "/home/collin/django1.10/django/db/migrations/executor.py", line
198, in apply_migration
state = migration.apply(state, schema_editor)
  File "/home/collin/django1.10/django/db/migrations/migration.py", line
123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state,
project_state)
  File "/home/collin/django1.10/django/db/migrations/operations/fields.py",
line 201, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
  File "/home/collin/django1.10/django/db/backends/base/schema.py", line
482, in alter_field
old_db_params, new_db_params, strict)
  File "/home/collin/django1.10/django/db/backends/base/schema.py", line
634, in _alter_field
params,
  File "/home/collin/django1.10/django/db/backends/base/schema.py", line
110, in execute
cursor.execute(sql, params)
  File "/home/collin/django1.10/django/db/backends/utils.py", line 79, in
execute
return super(CursorDebugWrapper, self).execute(sql, params)
  File "/home/collin/django1.10/django/db/backends/utils.py", line 64, in
execute
return self.cursor.execute(sql, params)
  File "/home/collin/django1.10/django/db/utils.py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/home/collin/django1.10/django/utils/six.py", line 685, in reraise
raise value.with_traceback(tb)
  File "/home/collin/django1.10/django/db/backends/utils.py", line 64, in
execute
return 

Backwards-compatibility import shims

[Marten Kenbeek]

As noted by 
Collin on deprecating old import paths:

I personally wouldn't mind if we didn't actually deprecate this, and left 
> these shims in a bit longer :). (Makes it just a hair easier for people 
> upgrading.) But that's just me.


There is very little maintenance overhead to keep backwards-compatible 
import shims longer than the current deprecation cycle.

Any thoughts on this?

-- 
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/4f0d299f-1ea5-4d79-b961-461a54c622ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

admin: implementing list_prefetch_related

[Riccardo Magliocchetti]

Hello,

the need to list an m2m relationship serialized in the admin list view happens 
quite often to me and overriding the queryset may not be as trivial as a 
ModelAdmin attribute. It makes sense to me to match what is possible with 
foreign keys and list_select_related.

Any opinion on implementing list_prefetch_related for ModelAdmin?

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.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/5683B12D.6000600%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Help needed with the MySQL max index length problem for Django 1.10

[Florian Apolloner]

On Monday, December 21, 2015 at 5:32:43 PM UTC+1, Tim Graham wrote:
>
> "This patch breaks on MySQL installations using the utf8mb4 charset, 
> because it breaks the index length limit - it comes out at a maximum of 254 
> * 4 = 1016 bytes whilst by default InnoDB can only index 767 bytes. I found 
> this because I am using utf8mb4 in django-mysql's tests.
>

Can the original Author of that quote shed more light on "breaking"? To my 
knowledge it just limits the size of the index to the first 767 byte and 
MySQL will give you a warning, so we should be fine, no? 

-- 
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/ac1bd7c0-6692-4caf-8087-0dc0208e6588%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: delegating our static file serving

[Florian Apolloner]

On Tuesday, December 29, 2015 at 6:31:02 PM UTC+1, David Evans wrote:
>
> 2. Serving media files is a slightly different case. WhiteNoise was 
> designed around the assumption that it's serving a set of 
> developer-supplied, public files which remain unchanged during the lifetime 
> of the process. This simplifies a lot of performance and security concerns 
> that come with serving mutable, user-supplied files. 
>

Speaking from a  security perspective: It is also important that WhiteNoise 
would serve Media files in a safe way, ie serving most files as attachments 
to prevent uploaded HTML files from starting an attack, preventing browser 
content type sniffing etc…

-- 
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/db7e7fe6-c735-43bb-a3f7-2bc809707032%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.