date:20141231

Re: [Django] #22571: Document implications of using auto_now_add=True and get_or_create

2014-12-31 Thread Django

#22571: Document implications of using auto_now_add=True and get_or_create
-+-
 Reporter:  nu.everest@… |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  integrityerror   | Triage Stage:  Accepted
  auto_now_add get_or_create |
  duplicatekey   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by iambibhas):

 * cc: me@… (added)


Comment:

 Replying to [comment:5 charettes]:
 > {{{#!python
 > In [1]: from app.models import Auto, Default, timezone
 >
 > In [2]: added = timezone.now()
 >
 > In [3]: Auto.objects.get_or_create(added=added)
 > Out[3]: (, True)
 >
 > In [4]: Auto.objects.get_or_create(added=added)
 > Out[4]: (, True)
 >
 > In [5]: Default.objects.get_or_create(added=added)
 > Out[5]: (, True)
 >
 > In [6]: Default.objects.get_or_create(added=added)
 > Out[6]: (, False)
 > }}}

 Isn't this expected? The doc says -

 > DateField.auto_now_add
 >
 > Automatically set the field to now when the object is first created.
 Useful for creation of timestamps. Note that the current date is *always*
 used; it’s not just a default value that you can override.

 And the code also shows that the value with always set to `timezone.now()`
 if `auto_now_add` is set, even if you provide a value when creating it.

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

Re: [Django] #23749: Document how to get the database alias in migrations

2014-12-31 Thread Django

#23749: Document how to get the database alias in migrations
--+
 Reporter:  alfredperlstein   |Owner:  splbio
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  migrations dbrouter   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by splbio):

 If this looks OK I would like to document the {{{connection}}} handle
 being inside the {{{schema_editor}}} on another page.  Please let me know
 if this document addition is in the correct path and if so I will look
 into augmenting the {{{schema_editor}}} page.

 Is it the norm to document member variables?  Is there an existing
 example?  The reason I ask is that {{{schema_editor}}} only has its
 methods documented and no member variables.

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

Re: [Django] #23749: Document how to get the database alias in migrations

2014-12-31 Thread Django

#23749: Document how to get the database alias in migrations
--+
 Reporter:  alfredperlstein   |Owner:  splbio
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  migrations dbrouter   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by splbio):

 * owner:  nobody => splbio
 * status:  new => assigned


Comment:

 I have created a pull request against documentation here:

 https://github.com/django/django/pull/3822

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

Re: [Django] #24067: Renaming Models asks for double confirmation (and doesn't preserve relationships?)

2014-12-31 Thread Django

#24067: Renaming Models asks for double confirmation (and doesn't preserve
relationships?)
+--
 Reporter:  doepunk |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by doepunk:

Old description:

> When renaming a model (from OldModel to NewModel) I noticed that
> makemigrations asks for confirmation if I had renamed NewModel to
> OldModel. Which is great that that was detected and the confirmation
> helps to get a correct migration file, which makes this step
> reproducible. The Model in question did not involve any foreign keys to
> or from it. However when I ran the migrate, I got this message
>

> {{{
> The following content types are stale and need to be deleted:
>
>  | 
>
> Any objects related to these content types by a foreign key will also
> be deleted. Are you sure you want to delete these content types?
> If you're unsure, answer 'no'.
> }}}
>
> I'm unsure what's going on here. But shouldn't renaming involve the
> automatic deletion of the old name and replacing the foreign keys with
> the new database table keys? All without a need for confirmation. Or at
> least if there are no foreign keys as in my case, the confirmation seems
> unnecessary and it only makes it harder to run the migration unsupervised
> and it introduces a potential error source. Assuming that all data from
> the old table were copied to the new table and all foreign key
> relationships copied and updated as well, I don't see a use case for
> keeping the old table and "related objects" around. And as for the case
> that there were any changes in relationships reflected in the Models
> (other than the name change) this could be detected and confirmed in the
> makemigrations stage. (For example if there were still references to
> OldName in the code when OldName no longer exists as a class, this would
> result in a syntax error, or if a Foreign Key attribute to OldModel was
> deleted and not replaced with NewModel Foreign Key it's just akin to a
> field deletion). It just seems more reproducible to keep all
> confirmations in the makemigration stage.

New description:

 When renaming a model (from OldModel to NewModel) I noticed that
 makemigrations asks for confirmation if I had renamed NewModel to
 OldModel. Which is great that that was detected and the confirmation helps
 to get a correct migration file, which makes this step reproducible. The
 Model in question did not involve any foreign keys to or from it. However
 when I ran the migrate, I got this message


 {{{
 The following content types are stale and need to be deleted:

  | 

 Any objects related to these content types by a foreign key will also
 be deleted. Are you sure you want to delete these content types?
 If you're unsure, answer 'no'.
 }}}

 I'm unsure what's going on here. But shouldn't renaming involve the
 automatic deletion of the old name and replacing the foreign keys with the
 new database table keys? All without a need for confirmation. Or at least
 if there are no foreign keys as in my case, the confirmation seems
 unnecessary and it only makes it harder to run the migration unsupervised
 and it introduces a potential error source. Assuming that all data from
 the old table were copied to the new table and all foreign key
 relationships copied and updated as well, I don't see a use case for
 keeping the old table and "related objects" around. And as for the case
 that there were any changes in relationships reflected in the Models
 (other than the name change) this could be detected and confirmed in the
 makemigrations stage. (For example if there were still references to
 OldName in the code when OldName no longer exists as a class, this would
 result in an exception, or if a Foreign Key attribute to OldModel was
 deleted and not replaced with NewModel Foreign Key it's just akin to a
 field deletion). It just seems more reproducible to keep all confirmations
 in the makemigration stage.

--

--
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

Re: [Django] #24067: Renaming Models asks for double confirmation (and doesn't preserve relationships?)

2014-12-31 Thread Django

#24067: Renaming Models asks for double confirmation (and doesn't preserve
relationships?)
+--
 Reporter:  doepunk |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by doepunk):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Migrations
 * needs_tests:   => 0
 * needs_docs:   => 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/065.ff75e36bb35a3b349b2177adc98680fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24067: Renaming Models asks for double confirmation (and doesn't preserve relationships?)

2014-12-31 Thread Django

#24067: Renaming Models asks for double confirmation (and doesn't preserve
relationships?)
---+
Reporter: doepunk| Owner: nobody
Type: Bug| Status: new
Component: Uncategorized |Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
When renaming a model (from OldModel to NewModel) I noticed that
makemigrations asks for confirmation if I had renamed NewModel to
OldModel. Which is great that that was detected and the confirmation helps
to get a correct migration file, which makes this step reproducible. The
Model in question did not involve any foreign keys to or from it. However
when I ran the migrate, I got this message

{{{
The following content types are stale and need to be deleted:

Any objects related to these content types by a foreign key will also
be deleted. Are you sure you want to delete these content types?
If you're unsure, answer 'no'.
}}}

I'm unsure what's going on here. But shouldn't renaming involve the
automatic deletion of the old name and replacing the foreign keys with the
new database table keys? All without a need for confirmation. Or at least
if there are no foreign keys as in my case, the confirmation seems
unnecessary and it only makes it harder to run the migration unsupervised
and it introduces a potential error source. Assuming that all data from
the old table were copied to the new table and all foreign key
relationships copied and updated as well, I don't see a use case for
keeping the old table and "related objects" around. And as for the case
that there were any changes in relationships reflected in the Models
(other than the name change) this could be detected and confirmed in the
makemigrations stage. (For example if there were still references to
OldName in the code when OldName no longer exists as a class, this would
result in a syntax error, or if a Foreign Key attribute to OldModel was
deleted and not replaced with NewModel Foreign Key it's just akin to a
field deletion). It just seems more reproducible to keep all confirmations
in the makemigration stage.

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

Re: [Django] #23940: Disallow/warn on fields named exact (was: problem when i access related object)

2014-12-31 Thread Django

#23940: Disallow/warn on fields named exact
-+-
 Reporter:  zhiyajun11   |Owner:  nobody
 Type:  New feature  |   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:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * version:  1.7 => master
 * type:  Bug => New feature


Comment:

 I think a system check that gives a warning or error on fields named
 `exact` would be appropriate.

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

Re: [Django] #23366: Workaround for `ValueError: Dependency on app with no migrations` in #22848 may need attention

2014-12-31 Thread Django

#23366: Workaround for `ValueError: Dependency on app with no migrations` in 
#22848
may need attention
+
 Reporter:  stevejalim  |Owner:  yakky
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+

Comment (by Tim Graham ):

 In [changeset:"f461bc02cbfa7c04748e4b2392586fa3835330b1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="f461bc02cbfa7c04748e4b2392586fa3835330b1"
 [1.7.x] Fixed #23366 -- Fixed a crash with the migrate --list command.

 Backport of b4bdd5262b18644456d12a00d475adf9897a9255 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/068.f23647481a25aee285356f84880766ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23749: Document how to get the database alias in migrations

2014-12-31 Thread Django

#23749: Document how to get the database alias in migrations
--+
 Reporter:  alfredperlstein   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  migrations dbrouter   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timgraham):

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


Comment:

 Please see [https://docs.djangoproject.com/en/dev/internals/contributing
 /writing-documentation/ Writing documentation].

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

Re: [Django] #23366: Workaround for `ValueError: Dependency on app with no migrations` in #22848 may need attention

2014-12-31 Thread Django

#23366: Workaround for `ValueError: Dependency on app with no migrations` in 
#22848
may need attention
+
 Reporter:  stevejalim  |Owner:  yakky
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"b4bdd5262b18644456d12a00d475adf9897a9255"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b4bdd5262b18644456d12a00d475adf9897a9255"
 Fixed #23366 -- Fixed a crash with the migrate --list command.
 }}}

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

Re: [Django] #23366: Workaround for `ValueError: Dependency on app with no migrations` in #22848 may need attention

2014-12-31 Thread Django

#23366: Workaround for `ValueError: Dependency on app with no migrations` in 
#22848
may need attention
+
 Reporter:  stevejalim  |Owner:  yakky
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+

Comment (by timgraham):

 Not sure why the test doesn't reproduce the failure, but I can reproduce
 this manually. Since apps without migrations will be obsolete in 1.9, I
 don't think this is worth spending any more time on so I'll just commit
 this without a test.

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

Re: [Django] #23749: Document how to get the database alias in migrations

2014-12-31 Thread Django

Comment (by splbio):

Can someone give me a pointer to how to edit the page

https://docs.djangoproject.com/en/1.7/topics/migrations/#data-migrations

-Or-

https://docs.djangoproject.com/en/1.7/ref/schema-editor/

To be perfectly honest the addition to the RunPython section

(https://github.com/django/django/blob/aa5ef0d4fc67a95ac2a5103810d0c87d8c547bac/docs/ref
/migration-operations.txt#L316-L322) is not something that I would have
been able to find via google, nor is it likely I would have been able to
understand it.

I'm perfectly willing to update the docs for the migration or
schema_editor pages, I just need a pointer how to get started. Is it a
wiki I can log into? Or is there a git repo I can clone?

Please advise.

thank you!

-Alfred

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

Re: [Django] #23749: Document how to get the database alias in migrations

2014-12-31 Thread Django

#23749: Document how to get the database alias in migrations
-+-
 Reporter:  alfredperlstein  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.7
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  migrations dbrouter  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


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

Re: [Django] #24008: ValidationError crashes if initialised with a list that includes a ValidationError instance initialised with a dict.

2014-12-31 Thread Django

#24008: ValidationError crashes if initialised with a list that includes a
ValidationError instance initialised with a dict.
-+-
 Reporter:  seansean49   |Owner:  GreyZmeem
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.7
 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:"8de2a44064ca11749579a5887f59821fa35e1fdc"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8de2a44064ca11749579a5887f59821fa35e1fdc"
 [1.7.x] Fixed #24008 -- Fixed ValidationError crash with list of dicts.

 Backport of 7a878ca5cb50ad65fc465cb263a44cc93629f75c 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/068.e0fc22370be88665a687a429598b2716%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22295: admin/base.html only shows #user-tools when user is staff

2014-12-31 Thread Django

#22295: admin/base.html only shows #user-tools when user is staff
-+-
 Reporter:  wouter@… |Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  user-tools admin | Triage Stage:  Ready for
  base template  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * owner:   => Tim Graham 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"46068d850d8debd3611ed6499d48b9907bf07ef6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="46068d850d8debd3611ed6499d48b9907bf07ef6"
 Fixed #22295 -- Replaced permission check for displaying admin user-tools
 }}}

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

Re: [Django] #24064: Spatialite tests could use or create real database

2014-12-31 Thread Django

#24064: Spatialite tests could use or create real database
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Tests don't pass on Jenkins.

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

Re: [Django] #22295: admin/base.html only shows #user-tools when user is staff

2014-12-31 Thread Django

#22295: admin/base.html only shows #user-tools when user is staff
-+-
 Reporter:  wouter@… |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  user-tools admin | Triage Stage:  Ready for
  base template  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * stage:  Accepted => Ready for checkin


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

Re: [Django] #24064: Spatialite tests could use or create real database

2014-12-31 Thread Django

#24064: Spatialite tests could use or create real database
-+-
 Reporter:  coldmind |Owner:  coldmind
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   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 coldmind):

 * owner:  nobody => coldmind
 * status:  new => assigned
 * has_patch:  0 => 1
 * cc: coldmind (added)


Comment:

 https://github.com/django/django/pull/3821

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

Re: [Django] #24008: ValidationError crashes if initialised with a list that includes a ValidationError instance initialised with a dict.

2014-12-31 Thread Django

#24008: ValidationError crashes if initialised with a list that includes a
ValidationError instance initialised with a dict.
-+-
 Reporter:  seansean49   |Owner:  GreyZmeem
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.7
 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"7a878ca5cb50ad65fc465cb263a44cc93629f75c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7a878ca5cb50ad65fc465cb263a44cc93629f75c"
 Fixed #24008 -- Fixed ValidationError crash with list of dicts.
 }}}

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

Re: [Django] #24008: ValidationError crashes if initialised with a list that includes a ValidationError instance initialised with a dict.

2014-12-31 Thread Django

#24008: ValidationError crashes if initialised with a list that includes a
ValidationError instance initialised with a dict.
-+-
 Reporter:  seansean49   |Owner:  GreyZmeem
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  1.7
 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_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

Re: [Django] #24059: app_label not handled when set to the same project name in all the django app

2014-12-31 Thread Django

#24059: app_label not handled when set to the same project name in all the 
django
app
+--
 Reporter:  foxmask |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by shaib):

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


Comment:

 In the second paragraph in my previous comment I explained that once you
 set the model's app_label, Django treats it as if it belonged to the other
 app. Again: Your model with `app_label = 'foobar'` belongs to the `foobar`
 app, and the fact that it is defined in `foxmask/models.py` does not
 matter.

 If this is still not clear to you, as I said, please use Django's support
 channels.

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

Re: [Django] #24064: Spatialite tests could use or create real database

2014-12-31 Thread Django

#24064: Spatialite tests could use or create real database
-+-
 Reporter:  coldmind |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   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):

 * severity:  Normal => Release blocker


Comment:

 This is a release blocker as it causes the test from #12118 to fail on
 [http://djangoci.com/job/django-master-trusty/ django-master-trusty].

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

Re: [Django] #23359: Add ability to show the migration plan

2014-12-31 Thread Django

#23359: Add ability to show the migration plan
-+-
 Reporter:  Markush2010  |Owner:  MarkusH
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  master
 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"a1487deebff7bf27a4946a9f5ddd68154fa4834d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a1487deebff7bf27a4946a9f5ddd68154fa4834d"
 Fixed #23359 -- Added showmigrations command to list migrations and plan.

 Thanks to Collin Anderson, Tim Graham, Gabe Jackson, and Marc Tamlyn
 for their input, ideas, and 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/069.975fb55e7ac20c5e4d5a0e1e9c5c0d4e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22232: Template extends tag can cause recursion

2014-12-31 Thread Django

#22232: Template extends tag can cause recursion
-+
 Reporter:  galedragon   |Owner:  ChillarAnand
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+
Changes (by ChillarAnand):

 * owner:  Saidin7979 => ChillarAnand


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

Re: [Django] #23359: Add ability to show the migration plan

2014-12-31 Thread Django

#23359: Add ability to show the migration plan
-+-
 Reporter:  Markush2010  |Owner:  MarkusH
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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):

 * stage:  Accepted => Ready for checkin


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

Re: [Django] #24064: Spatialite tests could use or create real database

2014-12-31 Thread Django

#24064: Spatialite tests could use or create real database
-+-
 Reporter:  coldmind |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
-+-

Comment (by coldmind):

 An idea how this could be resolved.
 https://gist.github.com/coldmind/be61c330c7e56974bb51

 This looks more good than creating meta magic on classes to make these
 fields to be dynamic

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

Re: [Django] #18399: Add a `for_concrete_model` kwarg to `ContentTypeManager.get_for_models?`

2014-12-31 Thread Django

#18399: Add a `for_concrete_model` kwarg to `ContentTypeManager.get_for_models?`
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.4
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  contenttypes proxy   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 This ticket adds a feature required to solve #11154.

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

Re: [Django] #22352: GeoQuerySet methods: support lookups on reversed o2o relationships as field_name

2014-12-31 Thread Django

#22352: GeoQuerySet methods: support lookups on reversed o2o relationships as
field_name
-+-
 Reporter:  pchiquet |Owner:  anonymous
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  geodjango,   | Triage Stage:  Accepted
  GeoQuerySet|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kostko):

 * cc: jernej@… (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/066.9339e4404b8beebdd257ed78bc8da7dd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18586: Rewrite unit tests migrated from doctests

2014-12-31 Thread Django

#18586: Rewrite unit tests migrated from doctests
-+-
 Reporter:  konk |Owner:
 Type:   |  ChillarAnand
  Cleanup/optimization   |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  unit tests   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"89527576980ff14309990c152e5904ddd5ca3df7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="89527576980ff14309990c152e5904ddd5ca3df7"
 Refs #18586 -- Split up tests.defer.DeferTests.test_defer
 }}}

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

Re: [Django] #22341: Split django.db.models.fields.related into multiple modules.

2014-12-31 Thread Django

#22341: Split django.db.models.fields.related into multiple modules.
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.8-alpha| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 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/064.45093ee17fb81edbc139dc5ef9291e4c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17627: contrib.admin.util is misnamed

2014-12-31 Thread Django

#17627: contrib.admin.util is misnamed
--+
 Reporter:  PaulM |Owner:  lukegb
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"4abfa73c1861c53d43f0448726346866b04b9b72"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4abfa73c1861c53d43f0448726346866b04b9b72"
 [1.7.x] Renamed tests for util -> utils moves; refs #17627.

 Backport of 8a9b0c15a6c0ef60dea3ba3042317520bc201206 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/063.22827f34c004c14ce606aab209cb5cfb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17627: contrib.admin.util is misnamed

2014-12-31 Thread Django

#17627: contrib.admin.util is misnamed
--+
 Reporter:  PaulM |Owner:  lukegb
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"8a9b0c15a6c0ef60dea3ba3042317520bc201206"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8a9b0c15a6c0ef60dea3ba3042317520bc201206"
 Renamed tests for util -> utils moves; refs #17627.
 }}}

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

Re: [Django] #24066: Django 1.6 Postgis 2.x detection broken

2014-12-31 Thread Django

#24066: Django 1.6 Postgis 2.x detection broken
---+--
 Reporter:  Matthias84 |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  GIS|  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords:  postgis detection  | Triage Stage:  Unreviewed
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
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Could you please try with Django 1.7.1? Django 1.6 is only receiving
 security updates, so if this issue is fixed in 1.7, we can close this
 ticket.

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

Re: [Django] #23861: Fields referenced in migrations cannot be (re)moved, even if migrations have been squashed

2014-12-31 Thread Django

#23861: Fields referenced in migrations cannot be (re)moved, even if migrations
have been squashed
-+
 Reporter:  spookylukey  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   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 MarkusH):

 While looking at Tim's patch for #23891 I came up with the following:

 {{{#!python
 class Field(...):
 deprecated_for_migrations = False
 removed_for_migrations = False

 def check(...):
 # ...
 errors.extend(self._check_migration_availability(...))
 # ...

 def _check_migration_availability(self):
 if self.__class__.removed_for_migrations:
 return [
 checks.Error(
 'The field %s has been removed except for support in
 historical migrations.' % self.__class__.__name__,
 hint=None,
 obj=self,
 id='fields.EXXX',
 )
 ]
 elif self.__class__.deprecated_for_migrations:
 return [
 checks.Warning(
 'The field %s has been deprecated. Support for it
 (except in historical migrations) will be removed according to the
 deprecation timeline' % self.__class__.__name__,
 hint=None,
 obj=self,
 id='fields.WXXX',
 )
 ]

 class IPAddressField(...):
 deprecated_for_migrations = True
 }}}

 This comes with one drawback that Tim correctly noted:

 > It seems nice to be able to have a unique code for each field so they
 can be silenced if desired, rather than one code for all deprecations, but
 this seems possible only if we use the model field class name to generate
 the code, in which case we'll have to depart from the usual numbering
 scheme.

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

[Django] #24066: Django 1.6 Postgis 2.x detection broken

2014-12-31 Thread Django

#24066: Django 1.6 Postgis 2.x detection broken
+---
Reporter: Matthias84 | Owner: nobody
Type: Bug | Status: new
Component: GIS |Version: 1.6
Severity: Normal | Keywords: postgis detection
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
+---
Hi, I realy enjoy (geo)Django to rapidly develop smal GIS applications for
some time now. Unfortunatly, I guess I found a bug:

If you install Django and try to add GIS functionality thanks to
Postgres+PostGIS, django seems to be unable to detect PostGIS correctly
and reports at syncdb and similat commands:

{{{
Cannot determine PostGIS version for database "django_geotest". GeoDjango
requires at least PostGIS version 1.3. Was the database created from a
spatial database template?
}}}

There is a workaround by faking the postgis version manually, that work
for me: https://stackoverflow.com/questions/10584852/my-postgis-database-
looks-fine-but-geodjango-thinks-otherwise-why

My setup:
* Linux Mint 17
* Python 2.7 and venv
* Django 1.6.8
* Postgres 9.3 and PostGIS 2.1 following the official tutorial

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

Re: [Django] #22340: Legacy Table Creation Methods Not Properly Deprecated

2014-12-31 Thread Django

#22340: Legacy Table Creation Methods Not Properly Deprecated
-+-
 Reporter:  mlavin   |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"09bce0b2cb6813e1b7acf184a1e26402736618a0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="09bce0b2cb6813e1b7acf184a1e26402736618a0"
 Fixed #22340 -- Removed DatabaseCreation deprecation from timeline.
 }}}

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

Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-12-31 Thread Django

#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  richardhowardsparx   |Owner:
 |  piotrpawlaczek
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bump_prefix  | Triage Stage:  Ready for
  subquery alias |  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:"e11ff3975f69b96521d94417bbe4125f4abb2774"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e11ff3975f69b96521d94417bbe4125f4abb2774"
 [1.7.x] Fixed #23758 -- Allowed more than 5 levels of subqueries

 Refactored bump_prefix() to avoid infinite loop and allow more than
 than 5 subquires by extending the alphabet to use multi-letters.

 Backport of 41fc1c0b5eac156e200a10233c7c9210a1c0fed8 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/076.e1880131521ba60f6684f4037fac055f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-12-31 Thread Django

#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  richardhowardsparx   |Owner:
 |  piotrpawlaczek
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bump_prefix  | Triage Stage:  Ready for
  subquery alias |  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:"63dee96cc7a3c929e16f88f2039812490b4b02b2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="63dee96cc7a3c929e16f88f2039812490b4b02b2"
 Fixed test from refs #23758.
 }}}

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

Re: [Django] #22340: Legacy Table Creation Methods Not Properly Deprecated

2014-12-31 Thread Django

#22340: Legacy Table Creation Methods Not Properly Deprecated
-+-
 Reporter:  mlavin   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 OK with the plan. I'm just not sure if we really have to drop support for
 apps without migrations, but that's not the subject of this ticket.

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

Re: [Django] #24065: aggregate dont find column of annotate

2014-12-31 Thread Django

#24065: aggregate dont find column of annotate
-+-
 Reporter:  mateuspadua  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  aggregate annotate   | Triage Stage:
  fielderror |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mateuspadua):

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


Old description:

> If we try this query, everything works normally
>
> {{{
> Entry.objects.annotate(num_authors=Count('authors')).aggregate(Avg('num_authors'))
> }}}
>
> but if we try the one below, it does not find the column
> ''authors__count' to the aggregation
>
> {{{
> Entry.objects.annotate(Count('authors')).aggregate(Avg('authors__count'))
> }}}
>
> I believe it is a problem because the exception tells us we could use the
> column authors__count
>
> This is what the exception says:
>
> '''FieldError: Cannot resolve keyword 'count' into field. Choices are:
> email, entry, id, name, authors__count''' <- see the field here.
>
> Thanks.

New description:

 If we try this query, everything works normally

 {{{
 
Entry.objects.annotate(num_authors=Count('authors')).aggregate(Avg('num_authors'))
 }}}

 but if we try the one below, it does not find the column
 {{{authors__count}}} to the aggregation

 {{{
 Entry.objects.annotate(Count('authors')).aggregate(Avg('authors__count'))
 }}}

 I believe it is a problem because the exception tells us we could use the
 column {{{authors__count}}}

 This is what the exception says:

 {{{FieldError: Cannot resolve keyword 'count' into field. Choices are:
 email, entry, id, name, authors__count}}} <- see the field here.

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

[Django] #24065: aggregate dont find column of annotate

2014-12-31 Thread Django

#24065: aggregate dont find column of annotate
-+-
 Reporter:  mateuspadua  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Database layer   |Version:  1.7
  (models, ORM)  |   Keywords:  aggregate annotate
 Severity:  Normal   |  fielderror
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 If we try this query, everything works normally

 {{{
 
Entry.objects.annotate(num_authors=Count('authors')).aggregate(Avg('num_authors'))
 }}}

 but if we try the one below, it does not find the column ''authors__count'
 to the aggregation

 {{{
 Entry.objects.annotate(Count('authors')).aggregate(Avg('authors__count'))
 }}}

 I believe it is a problem because the exception tells us we could use the
 column authors__count

 This is what the exception says:

 '''FieldError: Cannot resolve keyword 'count' into field. Choices are:
 email, entry, id, name, authors__count''' <- see the field here.

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

Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-12-31 Thread Django

#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  richardhowardsparx   |Owner:
 |  piotrpawlaczek
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bump_prefix  | Triage Stage:  Ready for
  subquery alias |  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:"41fc1c0b5eac156e200a10233c7c9210a1c0fed8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="41fc1c0b5eac156e200a10233c7c9210a1c0fed8"
 Fixed #23758 -- Allowed more than 5 levels of subqueries

 Refactored bump_prefix() to avoid infinite loop and allow more than
 than 5 subquires by extending the alphabet to use multi-letters.
 }}}

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

Re: [Django] #23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix

2014-12-31 Thread Django

#23758: Going beyond 5 levels of subqueries causes AssertionError in bump_prefix
-+-
 Reporter:  richardhowardsparx   |Owner:
 |  piotrpawlaczek
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  bump_prefix  | Triage Stage:  Ready for
  subquery alias |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

Re: [Django] #22340: Legacy Table Creation Methods Not Properly Deprecated

2014-12-31 Thread Django

#22340: Legacy Table Creation Methods Not Properly Deprecated
-+-
 Reporter:  mlavin   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
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:"478d6a950361ef541ff40b51b7c04439647e0492"]:
 {{{
 #!CommitTicketReference repository=""
 revision="478d6a950361ef541ff40b51b7c04439647e0492"
 Copied BaseDatabaseCreation._digest() to SchemaEditor to remove
 dependency.

 refs #22340.
 }}}

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

Re: [Django] #22340: Legacy Table Creation Methods Not Properly Deprecated

2014-12-31 Thread Django

#22340: Legacy Table Creation Methods Not Properly Deprecated
-+-
 Reporter:  mlavin   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
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:"93d73dac91104fd82d44b0dd4521cfa4f31e02aa"]:
 {{{
 #!CommitTicketReference repository=""
 revision="93d73dac91104fd82d44b0dd4521cfa4f31e02aa"
 Moved DatabaseCreation.data_types properties to DatabaseWrapper.

 refs #22340.
 }}}

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

Re: [Django] #21414: Remove django.db.models.related.RelatedObject

2014-12-31 Thread Django

#21414: Remove django.db.models.related.RelatedObject
-+-
 Reporter:  akaariai |Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Yes

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

Re: [Django] #18399: Add a `for_concrete_model` kwarg to `ContentTypeManager.get_for_models?`

2014-12-31 Thread Django

#18399: Add a `for_concrete_model` kwarg to `ContentTypeManager.get_for_models?`
-+-
 Reporter:  charettes|Owner:  charettes
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.4
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  contenttypes proxy   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by thedrow):

 Does this resolve #11154 in any way?

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

Re: [Django] #10929: Support a default value for Sum (and possibly other aggregation functions)

2014-12-31 Thread Django

#10929: Support a default value for Sum (and possibly other aggregation 
functions)
-+-
 Reporter:  nolan|Owner:
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  aggregate annotate   | Triage Stage:  Accepted
  default|
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by devunt):

 Replying to [comment:12 jarshwah]:
 > @mrmachine that's not a bad argument to make. What we could support is:
 >
 > {{{
 > Sum('field', default=0)
 > }}}
 >
 > Which would then be returned from {{{ convert_value }}} in the case
 where the value is None. The argument against that is we'd be special-
 casing the Sum aggregate, while leaving other aggregates to use the
 Coalesce method. That's not such a big downside though.
 >
 > Does anyone else want to weigh in on this? Supporting a default=0 kwarg
 is a 4 line + docs change.

 +1 for this.

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

Re: [Django] #24064: Spatialite tests could use or create real database

2014-12-31 Thread Django

* stage: Unreviewed => Accepted

Comment:

Basically, the problem is the `type` field of the
`SpatialiteGeometryColumns` model depends on the Spatialite version. And
as this happens at import time, the test machinery has not yet done its
job.
See

https://github.com/django/django/blob/51890ce8898f821d28f2f6fb6071c936e9bd88f0/django/contrib/gis/db/backends/spatialite/models.py#L16-L19

It's not the only location in Django where we could take advantage of a
lazy model field instanciation, but I'm not aware of any such method
currently. Ideas?

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

49 matches

Mail list logo