Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

[Django]

#25313: Document how to migrate from a built-in User model to a custom User 
model
---+
 Reporter:  carljm |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 I did it at least twice. Unfortunately I don't remember all the details.

 I think a reasonable procedure is:

 1. Create a custom user model identical to `auth.User`, call it `User` (so
 many-to-many tables keep the same name) and set `db_table='auth_user'` (so
 it uses the same table)
 2. Throw away all your migrations
 3. Recreate a fresh set of migrations
 4. Sacrifice a chicken, perhaps two if you're anxious; also make a backup
 of your database
 5. Truncate the `django_migrations` table
 6. Fake-apply the new set of migrations
 7. Unset `db_table`, make other changes to the custom model, generate
 migrations, apply them

 It is highly recommended to do this on a database that enforces foreign
 key constraints. Don't try this on SQLite on your laptop and expect it to
 work on Postgres on the servers!

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e11b56d5e7781a8643edca9dd6bdcff4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

[Django]

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
--+
 Reporter:  kalium99  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 Well, there's [https://docs.djangoproject.com/en/1.8/topics/signals
 /#preventing-duplicate-signals dispatch_uid]... Not elegant for sure, but
 not really painful either.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b1dc31f55fca5435e39121fa97840ee8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are ACID. They are durable xor not.

[Django]

#25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are
ACID. They are durable xor not.
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"ea47a052ba7a097a98993c240ecea96a115f6c25" ea47a05]:
 {{{
 #!CommitTicketReference repository=""
 revision="ea47a052ba7a097a98993c240ecea96a115f6c25"
 Fixed #25311 -- Removed vague language about "partial commits" from docs.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.5e13fc1a3c3014f4db4ab4cd3b5eff3c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are ACID. They are durable xor not.

[Django]

#25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are
ACID. They are durable xor not.
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"58335a2c0b2a1af4783c712e9a532385e04f554c" 58335a2c]:
 {{{
 #!CommitTicketReference repository=""
 revision="58335a2c0b2a1af4783c712e9a532385e04f554c"
 [1.8.x] Fixed #25311 -- Removed vague language about "partial commits"
 from docs.

 Backport of ea47a052ba7a097a98993c240ecea96a115f6c25 from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f439dbc587bdd3ecddf0ae050f6c203d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25313: Document how to migrate from a built-in User model to a custom User model

[Django]

#25313: Document how to migrate from a built-in User model to a custom User 
model
---+
 Reporter:  carljm |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

 * component:  Migrations => Documentation
 * stage:  Unreviewed => Accepted


Old description:

> (I'd have thought we might already have a ticket for this, but I couldn't
> find it.)
>
> So far our answer here has been "sorry, you can't do it, unless you're
> very familiar with the depths of the migrations system and willing to put
> a lot of time into it."
>
> I don't believe that this is a tenable or defensible answer. It puts too
> many of our users, too frequently, into an impossible quandary. I think
> we need to clearly document how you can do it today, even if the process
> is nasty and ugly. Hopefully seeing that nasty and ugly documentation
> might clarify what could be improved to make the process less nasty and
> ugly.

New description:

 So far our answer here has been "sorry, you can't do it, unless you're
 very familiar with the depths of the migrations system and willing to put
 a lot of time into it."

 I don't believe that this is a tenable or defensible answer. It puts too
 many of our users, too frequently, into an impossible quandary. I think we
 need to clearly document how you can do it today, even if the process is
 nasty and ugly. Hopefully seeing that nasty and ugly documentation might
 clarify what could be improved to make the process less nasty and ugly.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a62274dbcadec0f89745f3a200727a50%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25313: Document how to migrate from a built-in User model to a custom User model

[Django]

#25313: Document how to migrate from a built-in User model to a custom User 
model
---+
   Reporter:  carljm   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  Migrations   |Version:  1.8
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 (I'd have thought we might already have a ticket for this, but I couldn't
 find it.)

 So far our answer here has been "sorry, you can't do it, unless you're
 very familiar with the depths of the migrations system and willing to put
 a lot of time into it."

 I don't believe that this is a tenable or defensible answer. It puts too
 many of our users, too frequently, into an impossible quandary. I think we
 need to clearly document how you can do it today, even if the process is
 nasty and ugly. Hopefully seeing that nasty and ugly documentation might
 clarify what could be improved to make the process less nasty and ugly.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.bd4aeab7050bc00e540295a23a9a888a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

[Django]

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
--+
 Reporter:  kalium99  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by carljm):

 Replying to [comment:13 aaugustin]:
 > I think we must require ready() methods to be idempotent. Strictly
 speaking this is backwards-incompatible. But it's also a good property.

 Ouch. That's quite a painful requirement, actually, given that e.g. we
 recommend registering signal handlers in `ready()`. I really think
 imposing an idempotency requirement on `ready()` must be a last resort, if
 there's any possible way Django could avoid double-calling it instead.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.3b73c748b949c203697486c20c3a82da%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

[Django]

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
--+
 Reporter:  kalium99  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 It appears that mod_wsgi has good reasons not to kill the Python
 interpreter in that case:
 https://twitter.com/aymericaugustin/status/636173067350376449

 I think we must require ready() methods to be idempotent. Strictly
 speaking this is backwards-incompatible. But it's also a good property.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.88f0088428a0eb5406b5d677d12d74c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25312: Bug: AutoField backed by Postgres 9+ creates error condition

[Django]

#25312: Bug: AutoField backed by Postgres 9+ creates error condition
-+-
 Reporter:  infintesimal |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  AutoField,   | Triage Stage:
  Postgres, Sequences|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by infintesimal):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> The essence of this bug report is that models.py creates an inherent
> conflict between default, autoincrementing id fields (AutoField) and what
> a postgres 9.x (9.4 in my case) assigns as the type for the auto
> incrementing field. When makemigration creates the sequence, the sequence
> is created as a big integer. However, the database table that uses the
> sequence (the id field) is created as an integer. So once the value of
> the sequence exceeds the maximum value of a 32 bit integer, the insert
> will fail.
>
> Below is models.py code and some psql command line foo to illustrate the
> problem
>
> {{{
> import datetime
> import hashlib
> import os
> from math import sqrt
> from random import Random
> from django.db import models
> from django.db.models.query import Q
> from django.utils.text import slugify
> from djangoratings.fields import RatingField
> from django_pgjson.fields import JsonBField
> from django_images.models import Image as BaseImage
> from django.utils import timezone
>
> class EventName(models.Model):
>   event_name = models.CharField(max_length=500, blank=False, null=False)
>   event_desc = models.CharField(max_length=500, blank=False, null=True)
>   event_creation_date =
> models.DateTimeField(auto_now_add=True,null=False)
>   event_update_date = models.DateTimeField(auto_now=True,null=False)
>
>   def __unicode__(self):
> return self.name
>
> }}}
>
> {{{
> steves_app=> \d eventlogs_eventname_id_seq
>  Sequence "public.eventlogs_eventname_id_seq"
> Column |  Type   |   Value
> ---+-+
>  sequence_name | name| eventlogs_eventname_id_seq
>  last_value| bigint  | 1
>  start_value   | bigint  | 1
>  increment_by  | bigint  | 1
>  max_value | bigint  | 9223372036854775807
>  min_value | bigint  | 1
>  cache_value   | bigint  | 1
>  log_cnt   | bigint  | 0
>  is_cycled | boolean | f
>  is_called | boolean | f
> Owned by: public.eventlogs_eventname.id
>
> steves_app=> \d eventlogs_eventname
> Table
> "public.eventlogs_eventname"
>Column|   Type   |
> Modifiers
> -+--+--
>  id  | integer  | not null default
> nextval('eventlogs_eventname_id_seq'::regclass)
>  event_name  | character varying(500)   | not null
>  event_desc  | character varying(500)   |
>  event_creation_date | timestamp with time zone | not null
>  event_update_date   | timestamp with time zone | not null
> Indexes:
> "eventlogs_eventname_pkey" PRIMARY KEY, btree (id)
> Referenced by:
> TABLE "eventlogs_event" CONSTRAINT
> "eventlog_event_id_id_153f5722b6e1dffb_fk_eventlogs_eventname_id" FOREIGN
> KEY (event_id_id) REFERENCES eventlogs_eventname(id) DEFERRABLE INITIALLY
> DEFERRED
>
> fitcode_app=> alter sequence eventlogs_eventname_id_seq restart with
> 4294967297;
> ALTER SEQUENCE
> fitcode_app=> insert into
> eventlogs_eventname(event_name,event_desc,event_creation_date,event_update_date)
> values ('foo','bar',now(),now());
> ERROR:  integer out of range
>
> }}}

New description:

 The essence of this bug report is that models.py creates an inherent
 conflict between default, autoincrementing id fields (AutoField) and what
 a postgres 9.x (9.4 in my case) assigns as the type for the auto
 incrementing field. When makemigration creates the sequence, the sequence
 is created as a big integer. However, the database table that uses the
 sequence (the id field) is created as an integer. So once the value of the
 sequence exceeds the maximum value of a 32 bit integer, the insert will
 fail.

 Below is models.py code and some psql command line foo to illustrate the
 problem

 {{{
 import datetime
 import hashlib
 import os
 from math import sqrt
 from random import Random
 from django.db import models
 from django.db.models.query import Q
 from django.utils.text import 

[Django] #25312: Bug: AutoField backed by Postgres 9+ creates error condition

[Django]

#25312: Bug: AutoField backed by Postgres 9+ creates error condition
--+
 Reporter:  infintesimal  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:|Version:  1.7
  Uncategorized   |
 Severity:  Normal|   Keywords:  AutoField, Postgres, Sequences
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The essence of this bug report is that models.py creates an inherent
 conflict between default, autoincrementing id fields (AutoField) and what
 a postgres 9.x (9.4 in my case) assigns as the type for the auto
 incrementing field. When makemigration creates the sequence, the sequence
 is created as a big integer. However, the database table that uses the
 sequence (the id field) is created as an integer. So once the value of the
 sequence exceeds the maximum value of a 32 bit integer, the insert will
 fail.

 Below is models.py code and some psql command line foo to illustrate the
 problem

 {{{
 import datetime
 import hashlib
 import os
 from math import sqrt
 from random import Random
 from django.db import models
 from django.db.models.query import Q
 from django.utils.text import slugify
 from djangoratings.fields import RatingField
 from django_pgjson.fields import JsonBField
 from django_images.models import Image as BaseImage
 from django.utils import timezone

 class EventName(models.Model):
   event_name = models.CharField(max_length=500, blank=False, null=False)
   event_desc = models.CharField(max_length=500, blank=False, null=True)
   event_creation_date = models.DateTimeField(auto_now_add=True,null=False)
   event_update_date = models.DateTimeField(auto_now=True,null=False)

   def __unicode__(self):
 return self.name

 }}}

 {{{
 steves_app=> \d eventlogs_eventname_id_seq
  Sequence "public.eventlogs_eventname_id_seq"
 Column |  Type   |   Value
 ---+-+
  sequence_name | name| eventlogs_eventname_id_seq
  last_value| bigint  | 1
  start_value   | bigint  | 1
  increment_by  | bigint  | 1
  max_value | bigint  | 9223372036854775807
  min_value | bigint  | 1
  cache_value   | bigint  | 1
  log_cnt   | bigint  | 0
  is_cycled | boolean | f
  is_called | boolean | f
 Owned by: public.eventlogs_eventname.id

 steves_app=> \d eventlogs_eventname
 Table "public.eventlogs_eventname"
Column|   Type   |
 Modifiers
 
-+--+--
  id  | integer  | not null default
 nextval('eventlogs_eventname_id_seq'::regclass)
  event_name  | character varying(500)   | not null
  event_desc  | character varying(500)   |
  event_creation_date | timestamp with time zone | not null
  event_update_date   | timestamp with time zone | not null
 Indexes:
 "eventlogs_eventname_pkey" PRIMARY KEY, btree (id)
 Referenced by:
 TABLE "eventlogs_event" CONSTRAINT
 "eventlog_event_id_id_153f5722b6e1dffb_fk_eventlogs_eventname_id" FOREIGN
 KEY (event_id_id) REFERENCES eventlogs_eventname(id) DEFERRABLE INITIALLY
 DEFERRED

 fitcode_app=> alter sequence eventlogs_eventname_id_seq restart with
 4294967297;
 ALTER SEQUENCE
 fitcode_app=> insert into
 
eventlogs_eventname(event_name,event_desc,event_creation_date,event_update_date)
 values ('foo','bar',now(),now());
 ERROR:  integer out of range

 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/055.6ee7c378ac0107a29ca924a85f3cd785%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14217: Add validation for model field name the same as the model name when using model inheritance

[Django]

#14217: Add validation for model field name the same as the model name when 
using
model inheritance
-+-
 Reporter:  willian  |Owner:  niall
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  model inheritance,   | Triage Stage:  Ready for
  ORM|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"4bc00defd0cf4de3baf90cad43da62e531987459" 4bc00de]:
 {{{
 #!CommitTicketReference repository=""
 revision="4bc00defd0cf4de3baf90cad43da62e531987459"
 Fixed #14217 -- Added validation for field name collision when using model
 inheritance.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.34d136643d469293b4b4c88323ce28a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25058: GenericRelation with related_query_name related instances not shown on delete confirmation page

[Django]

#25058: GenericRelation with related_query_name related instances not shown on
delete confirmation page
---+
 Reporter:  jmfederico |Owner:  sarthakmeh03
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by sarthakmeh03):

 * owner:  andersonresende => sarthakmeh03


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.aadcb5e1025a80800a936c62720aeda8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24743: Django 1.8.1 migrations are actually slower than 1.8?

[Django]

#24743: Django 1.8.1 migrations are actually slower than 1.8?
--+
 Reporter:  pzrq  |Owner:  MarkusH
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by hugotacito):

 The pstat file:
 https://www.dropbox.com/s/c18k409qvwgn2bl/migrate4.pstats.gz?dl=0

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.7bb514b87f404144811a4e92365ad27c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24743: Django 1.8.1 migrations are actually slower than 1.8?

[Django]

#24743: Django 1.8.1 migrations are actually slower than 1.8?
--+
 Reporter:  pzrq  |Owner:  MarkusH
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Migrations|  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by hugotacito):

 Hello markus, after running for some time it gets very slower (like 5
 minutes) in between the change of modules. It doesn't  go to endless loop.

 Example:

 Applying financial.0007_auto_20150819_1451... OK (24.984s)
 '''(long wait)'''
 Applying fleet.0004_auto_20150819_1451... OK (17.156s)
 '''(long wait)'''
 Applying parking.0004_auto_20150819_1451... OK (11.604s)
 '''(long wait)'''
 Applying poll.0014_auto_20150805_1413... OK (9.664s)
 Applying poll.0015_auto_20150819_1451... OK (34.831s)
 '''(long wait)'''
 Applying protocol.0003_auto_20150819_1451... OK (10.068s)

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.a75ab820b91e9b2926b929021b57c8f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24100: Make `post_migrate` dispatch the migration plan.

[Django]

#24100: Make `post_migrate` dispatch the migration plan.
-+
 Reporter:  charettes|Owner:  MarkusH
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by MarkusH):

 * cc: info+coding@… (removed)
 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6035f9589ba42c126505515647589318%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are ACID. They are durable xor not.

[Django]

#25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are
ACID. They are durable xor not.
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Sounds good to me.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.006260f847ecf609e18eec24d3ae8b07%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24590: Cache return value of `swappable_setting`

[Django]

#24590: Cache return value of `swappable_setting`
-+-
 Reporter:  knbk |Owner:  MarkusH
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MarkusH):

 * needs_docs:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.7effd2a148da3ccc8252bc977c142aa7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are ACID. They are durable xor not.

[Django]

#25311: Docs: "You may perform partial commits ..." Sorry you can't. Commits are
ACID. They are durable xor not.
--+
 Reporter:  guettli   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There is vague description on:
 https://docs.djangoproject.com/en/1.8/topics/db/transactions/#tying-
 transactions-to-http-requests

 "You may perform **partial** commits ..."


 Sorry, you can't. Commits are ACID. They are durable xor not. They can't
 be partial.


 Some years ago I was wondering why transactions in PostgreSQL are not
 nestable. I needed some time to understand it. The fact: Transaction can't
 be nested.

 I would write:

 "You may perform subtransactions via savepoints ..."

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.b08d34fc4ce42260bff7f6c5c5d536be%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25309: Docs: ATOMIC_REQUESTS is for **view** not http request

[Django]

#25309: Docs: ATOMIC_REQUESTS is for **view** not http request
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"2a1a085bf1355370205dd44fa60c6aab91ed0976" 2a1a085b]:
 {{{
 #!CommitTicketReference repository=""
 revision="2a1a085bf1355370205dd44fa60c6aab91ed0976"
 Fixed #25309 -- Corrected that ATOMIC_REQUESTS applies per view not per
 request.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.386c45b8b79422557184921a842e06bb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25309: Docs: ATOMIC_REQUESTS is for **view** not http request

[Django]

#25309: Docs: ATOMIC_REQUESTS is for **view** not http request
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by guettli):

 Wow, that was fast. Thank you :-)

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c5a2c9f320aeef076f489fd79beda71f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25310: GeoManager's distance() method doesn't work with lookups that span multiple relationships

[Django]

#25310: GeoManager's distance() method doesn't work with lookups that span 
multiple
relationships
-+-
 Reporter:  seddonym |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  GeoManager,  | Triage Stage:
  distance   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * needs_docs:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 `GeoQuerySet.distance()` is deprecated in 1.9 and replaced by the
 
[https://docs.djangoproject.com/en/dev/ref/contrib/gis/functions/#django.contrib.gis.db.models.functions.Distance
 Distance] database function. Could you please check if this issue is still
 relevant there and file a new ticket with an updated example, if so?
 Thanks!

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.27e42dfb3a74f2dd2a50d34321b246a3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25310: GeoManager's distance() method doesn't work with lookups that span multiple relationships

[Django]

#25310: GeoManager's distance() method doesn't work with lookups that span 
multiple
relationships
-+--
 Reporter:  seddonym |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  GIS  |Version:  1.8
 Severity:  Normal   |   Keywords:  GeoManager, distance
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+--
 It is not currently possible to use the GeoQuerySet's distance() method to
 make a query that spans multiple relationships.  For example:
 {{{

 from django.contrib.gis.db import models

 class Location(models.Model):
 point = models.PointField()

 objects = models.GeoManager()


 class Office(models.Model):
 location = models.ForeignKey(Location)

 objects = models.GeoManager()


 class Person(models.Model):
 office = models.ForeignKey(Office)

 objects = models.GeoManager()
 }}}

 It is possible to distance query the offices:
 {{{
 >>> point = Location.objects.first().point
 >>> Office.objects.distance(point, field_name='location__point')
 [, ]
 }}}
 But not people:
 {{{
 >>> Person.objects.distance(point,
 field_name='office__location__point')
 *** TypeError: ST_Distance output only available on GeometryFields.
 }}}
 The reason for this is because of the way
 `django.contrib.gis.db.models.query.GeoQuerySet._geo_field()`
 performs the check - it just looks for fields that are in the model
 class's `._meta.fields`.

 (Incidentally, I'm not sure this is the correct error message - actually
 it hasn't found the field at all, and should probably say so.)

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.8f7117aaa9f8a9bf6a8c56a6e0e6e1bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25309: Docs: ATOMIC_REQUESTS is for **view** not http request

[Django]

#25309: Docs: ATOMIC_REQUESTS is for **view** not http request
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"206534893fd4d86efe6bbe76ad261dc143c13328" 2065348]:
 {{{
 #!CommitTicketReference repository=""
 revision="206534893fd4d86efe6bbe76ad261dc143c13328"
 [1.8.x] Fixed #25309 -- Corrected that ATOMIC_REQUESTS applies per view
 not per request.

 Backport of 2a1a085bf1355370205dd44fa60c6aab91ed0976 from master
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ff9d389786e155c7583e1d7d1e10db22%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25308: Initial migrations not created if no app provided and MIGRATION_MODULES[app] overridden

[Django]

#25308: Initial migrations not created if no app provided and
MIGRATION_MODULES[app] overridden
+
 Reporter:  jsatt   |Owner:  jsatt
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by charettes):

 * stage:  Ready for checkin => Accepted


Comment:

 Hi jsatt, thanks for the report and patch.

 Please don't mark your own patch as RFC. Someone else has to review it and
 mark it so.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.4be95c4e5f897ac4f2fcb20490c7a6b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25309: Docs: ATOMIC_REQUESTS is for **view** not http request

[Django]

#25309: Docs: ATOMIC_REQUESTS is for **view** not http request
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Yes, that's correct.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.5e241ab62a2355d1f5be80c6bc9c96b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

[Django]

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
--+
 Reporter:  kalium99  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 Clearly the immediate answer to the OP is "don't execute queries at import
 time". But a `ready()` method could fail for another reasons. For instance
 it could import a dependency which isn't installed.

 In the scenario discussed here, mod_wsgi:

 1. fails to import the application object (that's your first traceback,
 which is fine)
 2. retries to import it in the same Python process (that's your second
 traceback)

 It's unclear to me that this is a good idea. If importing the WSGI
 application fails, I don't expect the Python environment to be reused. I'd
 like to know what Graham Dumpleton thinks about this.

 In the same situation, gunicorn reports that workers have failed to boot
 and doesn't do anything.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.9d973ef9c193635aae1f662272249c81%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #12952: Models history doesn't use verbose names

[Django]

#12952: Models history doesn't use verbose names
--+
 Reporter:  acangiano |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  1
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Some [https://groups.google.com/d/topic/django-
 developers/nELSu0S6N9M/discussion discussion on the mailing list]
 confirmed my feeling that we should fix #21113 first.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.bb2522e2595aa312d10312ac6ac9404e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25309: Docs: ATOMIC_REQUESTS is for **view** not http request

[Django]

#25309: Docs: ATOMIC_REQUESTS is for **view** not http request
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Ready for checkin


Comment:

 Yes, that looks correct to me.

 {{{#!diff
 diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
 index 7c569fe..331e117 100644
 --- a/docs/ref/settings.txt
 +++ b/docs/ref/settings.txt
 @@ -478,8 +478,8 @@ ATOMIC_REQUESTS

  Default: ``False``

 -Set this to ``True`` to wrap each HTTP request in a transaction on this
 -database. See :ref:`tying-transactions-to-http-requests`.
 +Set this to ``True`` to wrap each view in a transaction on this database.
 See
 +:ref:`tying-transactions-to-http-requests`.

  .. setting:: DATABASE-AUTOCOMMIT
  }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d29c5fc0fcff093fec0660494f582027%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25022: collectstatic create self-referential symlink

[Django]

#25022: collectstatic create self-referential symlink
-+
 Reporter:  aaugustin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by edmorley):

 * cc: emorley@… (added)


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.17a4225de91790d515119fbf188d722e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10941: Add a templatetag to generate querystrings (was: Add querystring helper methods to Page class)

[Django]

#10941: Add a templatetag to generate querystrings
-+
 Reporter:  benspaulding |Owner:
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  pagination   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * component:  Core (Other) => Template system


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.5135a608f95b0b2d5f09078c8f82636f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23833: Add a management command to drop all tables (was: drop all tables)

[Django]

#23833: Add a management command to drop all tables
-+-
 Reporter:  MattBlack85  |Owner:
 |  MattBlack85
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  assigned => closed
 * resolution:   => worksforme


Comment:

 Closing per comment 6, "With migrations you can just reverse the
 migrations with `./manage.py migrate appname zero`, which will clear
 everything as required."

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.88bbb1fa634442ec5904a9f5f2d5cd39%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25304: Allow management commands to check if database migrations are applied (was: Trying to create a super user before first migrate raise a database error)

[Django]

#25304: Allow management commands to check if database migrations are applied
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.8
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0
 * component:  contrib.auth => Core (Management commands)
 * easy:  1 => 0
 * has_patch:  1 => 0
 * type:  Cleanup/optimization => New feature
 * stage:  Unreviewed => Accepted


Comment:

 I don't think the exception catching solution would work perfectly. For
 example, there's no guarantee that the database exception is due to
 missing tables and not some other bad query, etc. A more viable solution
 might be to allow management commands to check if all database migrations
 are applied and to output a warning if not, similar to what `runserver`
 does. Accepting the ticket for investigation of that idea. #24484 is
 similar.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8bc0138f4407af63d6442d983553d0d3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25309: Docs: ATOMIC_REQUESTS is for **view** not http request

[Django]

#25309: Docs: ATOMIC_REQUESTS is for **view** not http request
--+
 Reporter:  guettli   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Current docs: https://docs.djangoproject.com/en/1.8/ref/settings/#atomic-
 requests

 {{{
 ATOMIC_REQUESTS
 Default: False

 Set this to True to wrap each HTTP request in a transaction on this
 database. See Tying transactions to HTTP requests.
 }}}

 According to my understanding (and the person sitting beside me) this is
 not correct.

 ATOMIC_REQUESTS ties the transaction to the **view**, not the http
 request.

 The middleware is part of the request. It is not inside the transaction.

 I think it should be:

 {{{
 Set this to True to wrap each view in a transaction on this database.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.5a87f0775ae6518012e5bfb581eb5ca9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24523: django.apps.registry.populate() does not handle failures in app_config.ready()

[Django]

#24523: django.apps.registry.populate() does not handle failures in
app_config.ready()
--+
 Reporter:  kalium99  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by kalium99):

 Replying to [comment:10 shaib]:
 > I suspect this report to be invalid.
 >
 > Just above the quoted note in `AppConfig.ready()`'s documentation,
 there's a warning: Avoid interacting with the database. The whole point of
 this report is "ready() failed when interacting with the database".
 >

 Hi,

 I'm not sure where that above quoted text is from, and the whole point of
 this report is certainly not that ready() failed when interacting with the
 database.

 The whole point of this bug report is that the code does one or more of
 the following:

 1) Gives really unhelpful errors that do not confer the cause of the
 problem.
 2) The specific block of code in DJango does not actually work in the way
 it was intended.

 > The issue is "concealed" because the app whose `ready()` happened to
 interact with the database is `django.contrib.admin`; the interaction
 happened because, as appears in the log above,
 > {{{
 > [Sun Mar 22 23:47:26 2015] [error] [client 127.0.0.1] File
 "/home/test/apps/partners/forms.py", line 44, in PartnerSelection
 > [Sun Mar 22 23:47:26 2015] [error] [client 127.0.0.1] (p.id,
 p.company_name) for p in Partner.objects.all()])
 > }}}
 > a query is executed in the import of a forms.py file.
 >
 > The code is, of course, cut, but this looks like a "choices" argument,
 and if so, it is not only a problem because of database-interaction-
 in-`ready()`, but because it is a classic application bug -- if you add a
 Partner, it won't show in the form; the form only lets you select the
 partners that were recorded when the app started. To solve both issues,
 use a `ModelChoiceField` instead.
 >

 Both of these points are well understood and accepted. In fact in an
 earlier message I said "Technically you could say this is NOTABUG, because
 the method clearly says it is not re-entrant. " , as well as saying "This
 situation is not ideal for a couple of reasons (not in the least that the
 field is not updated until a process is recycled)."

 This ticket is about the interplay between the 'app_config'  and 'ready'
 variables, and how perhaps they don't work quite as intended, and how
 changing the error message, or the code itself, could give a better user
 experience in such circumstances.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7b5dbd31379e2ac80c3f2f314d46a0a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25307: Cannot use .annotate with conditional expressions

[Django]

#25307: Cannot use .annotate with conditional expressions
-+-
 Reporter:  jproffitt|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * cc: josh.smeaton@… (added)
 * version:  1.8 => master
 * stage:  Unreviewed => Accepted


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b7c9e27ed2b49c576903e074ba1a0a60%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25304: Trying to create a super user before first migrate raise a database error

[Django]

#25304: Trying to create a super user before first migrate raise a database 
error
-+-
 Reporter:  mlorant  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by mlorant):

 I agree with you, a developer should understand that a missing table on a
 Django default command means the database has not been created yet.
 However, I sometimes answer to question even more... easy *cough*... (like
 "Why my page is not working and throw `name 'url' is not defined` in
 urls.py").

 After some thoughts, the idea to raise the exception again with a hint
 seems more friendly for both usages (new Django users and skilled one),
 but it is not urgent at all. Also, it needs to establish a list of
 commands to improve...

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.35a0393721d080a0853a82d3917c8dd1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25295: translation.override() context manager doesn't return to deactivated state when there's no activated language

[Django]

#25295: translation.override() context manager doesn't return to deactivated 
state
when there's no activated language
-+-
 Reporter:  neruson  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"c177d0690e08628ccb83b021d413ff461f7d6002" c177d069]:
 {{{
 #!CommitTicketReference repository=""
 revision="c177d0690e08628ccb83b021d413ff461f7d6002"
 [1.8.x] Fixed #25295 -- Restored 'no active translation' after language
 override

 Thanks David Nelson Adamec for the report and Tim Graham for the review.
 Backport of 9324935c3 from master.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e44019640856dcc834833e17a3164ffa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25295: translation.override() context manager doesn't return to deactivated state when there's no activated language

[Django]

#25295: translation.override() context manager doesn't return to deactivated 
state
when there's no activated language
-+-
 Reporter:  neruson  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.8
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"9324935c3e67c01f665df9dd3a7197a68f8365a8" 9324935c]:
 {{{
 #!CommitTicketReference repository=""
 revision="9324935c3e67c01f665df9dd3a7197a68f8365a8"
 Fixed #25295 -- Restored 'no active translation' after language override

 Thanks David Nelson Adamec for the report and Tim Graham for the review.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.861ee55446b85a68a515cc51d7ec1701%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25303: help_text on auth model field 'is_active' doesn't get translated (was: permission names aren't translated)

[Django]

#25303: help_text on auth model field 'is_active' doesn't get translated
---+--
 Reporter:  Wenze  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords:  admin translation  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.1bd4143ca2cb56cd8691e409381cc680%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25303: permission names aren't translated

[Django]

#25303: permission names aren't translated
---+--
 Reporter:  Wenze  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.8
 Severity:  Normal |   Resolution:
 Keywords:  admin translation  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by Wenze):

 * status:  closed => new
 * resolution:  duplicate =>


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.43888e9db65c0269538ac5e95b4607c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25303: permission names aren't translated

[Django]

#25303: permission names aren't translated
---+--
 Reporter:  Wenze  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.8
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  admin translation  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--

Comment (by Wenze):

 To me it seems that this isn't a permission in the database. Because it is
 available in the .po translation file, the permissions are not. It is a
 'help_text' on the model, see:
 https://github.com/django/django/blob/master/django/contrib/auth/models.py#L328

 And 'superuserstatus' and 'staffstatus' do get translated correctly, which
 are the same type of fields?

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.9ed0bdec065d745f7fda2e5741a5e3f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.