Re: [Django] #23522: reverse() should return a text string, not a byte string

[Django]

#23522: reverse() should return a text string, not a byte string
-+
 Reporter:  jdufresne|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  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 claudep):

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

Re: [Django] #23520: Custom Plural-Forms is ignored in django.po

[Django]

#23520: Custom Plural-Forms is ignored in django.po
-+-
 Reporter:  aruseni  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  gettext, plural- |  Needs documentation:  0
  forms  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * type:  Uncategorized => Cleanup/optimization
 * version:  1.7 => master
 * component:  Internationalization => Documentation
 * 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/065.c5e9d10667df26df32f991526b5436e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23520: Custom Plural-Forms is ignored in django.po

[Django]

#23520: Custom Plural-Forms is ignored in django.po
-+-
 Reporter:  aruseni  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.7
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  gettext, plural- |  Unreviewed
  forms  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aruseni):

 I see. Thank you!

 Probably it could be documented here:

 https://docs.djangoproject.com/en/dev/topics/i18n/translation/#pluralization

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

Re: [Django] #23516: ifchanged no longer works within an included template

[Django]

#23516: ifchanged no longer works within an included template
-+
 Reporter:  dracos   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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
-+

Comment (by funkybob):

 If the IfChanged tag had some identifying key, we could stash the details
 in the render_context and everything becomes simpler.

 That would also open the opportunity to use IfChanged with a key name
 instead of an expression, expanding the scope of use and avoiding
 duplicated work...

 The trick then becomes generating a key in cases where it's not specified
 but _should_ be consistent.  Using template name + tag instance comes to
 mind, but won't work when a template is included in multiple places
 

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

Re: [Django] #23516: ifchanged no longer works within an included template

[Django]

#23516: ifchanged no longer works within an included template
-+
 Reporter:  dracos   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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
-+

Comment (by duncanparkes):

 I've been doing a little bit of digging around in here, and the bug was
 already present in 1.6, just in slightly fewer circumstances. If you
 replace @dracos' template with

 {{{
 {% for item in list %}
   {% with bit='bit.html' %}
 {% include bit %}
   {% endwith %}
 {% endfor %}
 }}}
 you'll see failures in both 1.6 and 1.7.

 The problem is that `IfChangedNode` stores what it looked like last time
 in the context by setting it as `state_frame[self]`. We were only getting
 the right thing in 1.6 because it was using `ConstantIncludeNode`, which
 calls `get_template` in its `__init__()`. With a normal `IncludeNode`,
 which is all there is in 1.7, `get_template` is called in `render()`
 causing a new `IfChangedNode` object. When the new `IfChangedNode` is
 looked up in as `state_frame[self]` it's not the same `self`!

 Now I understand the problem, but I'm still not sure I have a solution.
 Perhaps `IfChangedNode` could be made to produce the same object rather
 than a new copy under the right circumstances, or perhaps we should store
 the previous version to compare to in `state_frame` using something other
 than `self` as the key.

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

Re: [Django] #23516: ifchanged no longer works within an included template

[Django]

#23516: ifchanged no longer works within an included template
-+
 Reporter:  dracos   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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
-+

Comment (by funkybob):

 I reworked the include tag significantly for 1.7.

 Previously there were two actual tag nodes, depending on if you passed an
 immediate string for the template name or not.

 However, this difference made it painful to do recursion in templates,
 forcing people to trip the dynamic include node lest they cause infinite
 recursion.

 I'll take a closer look tonight and see if I can pin down the cause --
 most likely it's the render context being pushed/popped.

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

Re: [Django] #23479: makemigrations geterates wrong migration for ForeignKey to unmanaged model

[Django]

#23479: makemigrations geterates wrong migration for ForeignKey to unmanaged 
model
---+--
 Reporter:  g1itch |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Migrations |  Version:  1.7
 Severity:  Normal |   Resolution:  duplicate
 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 Markush2010):

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


Comment:

 Looks like a duplicate of #23415 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/064.305c8dd2f7e9747a53d986dd29fc713e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23522: reverse() should return a text string, not a byte string

[Django]

#23522: reverse() should return a text string, not a byte string
-+--
 Reporter:  jdufresne|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  master
 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 jdufresne):

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


Comment:

 Pull request:

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

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

Re: [Django] #23335: Related fields pointing to custom fields that store different values in the database than the python representation do not remember selections

[Django]

#23335: Related fields pointing to custom fields that store different values in 
the
database than the python representation do not remember selections
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.7-rc-2
 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 thenewguy):

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


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

Re: [Django] #23335: Related fields pointing to custom fields that store different values in the database than the python representation do not remember selections

[Django]

#23335: Related fields pointing to custom fields that store different values in 
the
database than the python representation do not remember selections
---+--
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.7-rc-2
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by thenewguy):

 Sorry for the delayed response.  I didn't get a notice of activity for
 some reason.

 I am not sure exactly where the bug is.  This is from memory from awhile
 ago, but when the form is rendered the widget is passed the raw value of
 the relation (e.g. -200 instead of 1 for the int field in my demo).  So
 when the choice widget compares the value -200 against possible choice
 values, it doesn't match because it is comparing the db value against the
 to_python value.  The choices iterable that the widget checks for the
 value -200 in contains the to_python value that -200 was mapped to (i.e.
 1).

 I do not think the bug is in my code.  It seems to work for everything
 except for this issue with forms.

 Have I explained the problem well enough for you to reproduce/observe the
 symptoms?

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

[Django] #23522: reverse() should return a text string, not a byte string

[Django]

#23522: reverse() should return a text string, not a byte string
-+
 Reporter:  jdufresne|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 

 As of now, `reverse()` returns a byte string. It should return a Unicode
 string (or text). URLs are used as text in many different contexts: HTML
 template, mail, JSON, etc.

 Pull request to follow.

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

Re: [Django] #23487: save() returns error "Models aren't loaded yet."

[Django]

#23487: save() returns error "Models aren't loaded yet."
-+-
 Reporter:  nmarler  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.7
Component:  Documentation|   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |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/065.7d1b0079d4689673d21caaa76ca7714a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23242: Add an option to avoid slow date_hierarchy queries on a big tables (was: slow date_hierarchy on a big tables)

[Django]

#23242: Add an option to avoid slow date_hierarchy queries on a big tables
-+-
 Reporter:  meteozond|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  date_hierarchy   | Triage Stage:  Accepted
  datetimes dates|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

 * type:  Cleanup/optimization => New feature
 * 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.ab643a342317c94c434dfb6dabc7ed8d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23520: Custom Plural-Forms is ignored in django.po

[Django]

#23520: Custom Plural-Forms is ignored in django.po
-+-
 Reporter:  aruseni  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:   |  Version:  1.7
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  gettext, plural- |  Unreviewed
  forms  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 Clearly, Django doesn't support different plural forms per file, and I
 don't think that this is going to change (all catalogs are merged).
 Is there a good place where this could be documented?

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

Re: [Django] #23242: slow date_hierarchy on a big tables

[Django]

#23242: slow date_hierarchy on a big tables
-+-
 Reporter:  meteozond|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  date_hierarchy   |  Unreviewed
  datetimes dates|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 The alternative would be an option to show all months and days regardless
 of whether items exist on these dates.

 {{{
 date_hierarchy_existing_only = True  # default
 }}}

 The year part can be handled with range(min, max) which will be fast if
 the field is indexed.

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

Re: [Django] #23519: Invalid ContentType after running "migrate" command

[Django]

#23519: Invalid ContentType after running "migrate" command
+--
 Reporter:  humitos |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 timgraham):

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


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

Re: [Django] #23519: Invalid ContentType after running "migrate" command

[Django]

#23519: Invalid ContentType after running "migrate" command
+--
 Reporter:  humitos |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
+--

Comment (by humitos):

 Well, with the help of cramm (from Python Argentina) I found there is
 something weird at django-dbsettings here:

  * https://github.com/zlorf/django-
 dbsettings/blob/master/dbsettings/management.py#L13

 Not sure how to solve it yet, but at least, I can say it doesn't seem to
 be a Django Bug :)

 Thanks and sorry!

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

Re: [Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

[Django]

#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
+--
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 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 sir-sigurd):

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

[Django] #23521: removal of concrete Model from bases doesn't remove it from ModelState bases

[Django]

#23521: removal of concrete Model from bases doesn't remove it from ModelState
bases
---+
 Reporter:  sir-sigurd |  Owner:  sir-sigurd
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Steps to reproduce:

 * add `test` app with `models.py`:
 {{{
 class Thing(models.Model):
 pass


 class SuperThing(Thing):
 pass
 }}}

 * do

 {{{
 manage.py makemigrations test
 }}}


 * change `models.py`:
 {{{
 class SuperThing(models.Model):
 thing_ptr = models.AutoField(primary_key=True)
 }}}

 * do

 {{{
 manage.py makemigrations test
 }}}

 * do it one more time

 {{{
 manage.py makemigrations test
 }}}

 last command results in


 {{{
 django.db.migrations.state.InvalidBasesError: Cannot resolve bases for
 []
 This can happen if you are inheriting models from an app with migrations
 (e.g. contrib.auth)
  in an app with no migrations; see
 https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies for
 more
 }}}

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

Re: [Django] #23519: Invalid ContentType after running "migrate" command

[Django]

#23519: Invalid ContentType after running "migrate" command
+--
 Reporter:  humitos |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 humitos):

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


Comment:

 A new !ContentType object is created when I run "migrate" command. I
 connected the signal {{{post_save}}} and checked the {{{sender}}} and it's
 a {{{ContentType}}} with {{{instance.model}}} equal to {{{''}}}.

 How can I detect where is this !ContentType created?

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

[Django] #23520: Custom Plural-Forms is ignored in django.po

[Django]

#23520: Custom Plural-Forms is ignored in django.po
--+---
 Reporter:  aruseni   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Internationalization  |Version:  1.7
 Severity:  Normal|   Keywords:  gettext, plural-forms
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 I want to use a custom Plural-Forms scheme in my django.po for Russian,
 but when I change it, it does not affect the results of ungettext.

 I’ve found out that if I use the same translation file without Django,
 Plural-Forms works correctly.

 Here is the django.po file.

 {{{
 msgid ""
 msgstr ""
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2014-09-18 01:26+\n"
 "Language: ru\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
 "Plural-Forms: nplurals=4; plural=(n==1 ? 0 : n%10==1 && n%100!=11 ? 1 :
 n"
 "%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 2 : 3)\n"

 #: testapp/test.py:5
 #, python-format
 msgid "One new notification."
 msgid_plural "%(count)s new notifications."
 msgstr[0] "Одно новое оповещение."
 msgstr[1] "%(count)s новое оповещение."
 msgstr[2] "%(count)s новых оповещения."
 msgstr[3] "%(count)s новых оповещений."
 }}}

 If I run this

 {{{#!python
 import gettext

 filename = "testp/conf/locale/ru/LC_MESSAGES/django.mo"
 trans = gettext.GNUTranslations(open( filename, "rb" ) )
 trans.install()

 def translated_message(notifications_count):
 return trans.ungettext(
 "One new notification.",
 "%(count)s new notifications.",
 notifications_count
 ) % {"count": notifications_count}

 print translated_message(1)
 print translated_message(2)
 print translated_message(5)
 print translated_message(51)
 }}}

 The following is printed:

 {{{
 Одно новое оповещение.
 2 новых оповещения.
 5 новых оповещений.
 51 новое оповещение.
 }}}

 And this is exactly what I expect to be the result of ungettext.

 But the output is different when the same compiled translation file
 (django.mo) is used in a Django project.

 With django.utils.translation.ungettext it changes to this:

 {{{
 Одно новое оповещение.
 2 новое оповещение.
 5 новых оповещения.
 Одно новое оповещение.
 }}}

 It obviously means that in this case the forms (msgstr) are read
 correctly, but Plural-Forms is ignored (i.e. the regular scheme for
 Russian language is used instead of what I have defined).

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

[Django] #23519: Invalid ContentType after running "migrate" command

[Django]

#23519: Invalid ContentType after running "migrate" command
+
 Reporter:  humitos |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Hi folks!

 First of all, I'm not sure if this is a Django bug o something in my code
 (or 3rd app code). I tried debugging it by myself but I didn't get to the
 right port. So, I'm asking here.

 For some reason, after running "migrate" in a fresh db everything works
 fine but the second time it's ran (immediately after the first one has
 finished and the subsequents) I got this message:

 {{{
 $ ./manage.py migrate
 Operations to perform:
   Synchronize unmigrated apps: facebook_comments, stronghold, dbtemplates,
 django_comments, django_proofread, allauth, guardian, autocomplete_light,
 debug_toolbar, dbsettings, chap, django_extensions, impersonate,
 django_wysiwyg, disqus, notifier, crispy_forms
   Apply all migrations: core, account, reversion, league, admin,
 challenge, sessions, sites, auth, sponsor, notifications, contenttypes,
 flatpages, team, organization, easy_thumbnails, inspiration
 Synchronizing apps without migrations:
   Creating tables...
   Installing custom SQL...
   Installing indexes...
 Running migrations:
   No migrations to apply.
 The following content types are stale and need to be deleted:

 core |

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

 Type 'yes' to continue, or 'no' to cancel: yes
 $
 }}}

 These are the differences in the db dump files (after first "migrate"
 command compared with the second run):
 http://linkode.org/9OjIVmwW3YDDM4pTabHWX1

 {{{
 --- chap-migration-test.sql 2014-09-18 09:31:58.332672674 -0300
 +++ chap-migration-test-after-2nd-migrate.sql   2014-09-18
 09:32:17.148672191 -0300
 @@ -2756,7 +2756,6 @@
  49 Can add registration invitation 16  add_registrationinvitation
  50 Can change registration invitation  16
 change_registrationinvitation
  51 Can delete registration invitation  16
 delete_registrationinvitation
 -52 Can edit core non-model settings17  can_edit__settings
  53 Can add user18  add_user
  54 Can change user 18  change_user
  55 Can delete user 18  delete_user
 @@ -2909,6 +2908,7 @@
  202Can add group object permission 67  add_groupobjectpermission
  203Can change group object permission  67
 change_groupobjectpermission
  204Can delete group object permission  67
 delete_groupobjectpermission
 +205Can edit core non-model settings68  can_edit__settings
  \.


 @@ -2916,7 +2916,7 @@
  -- Name: auth_permission_id_seq; Type: SEQUENCE SET; Schema: public;
 Owner: postgres
  --

 -SELECT pg_catalog.setval('auth_permission_id_seq', 204, true);
 +SELECT pg_catalog.setval('auth_permission_id_seq', 205, true);


  --
 @@ -3279,7 +3279,6 @@
  14 report  corereport
  15 rulecorerule
  16 registration invitation coreregistrationinvitation
 -17 corecore
  18 userchallenge   user
  19 goalchallenge   goal
  20 user goal   challenge   usergoal
 @@ -3330,6 +3329,7 @@
  65 notificationnotifiernotification
  66 user object permission  guardianuserobjectpermission
  67 group object permission guardiangroupobjectpermission
 +68 corecore
  \.


 @@ -3337,7 +3337,7 @@
  -- Name: django_content_type_id_seq; Type: SEQUENCE SET; Schema: public;
 Owner: postgres
  --

 -SELECT pg_catalog.setval('django_content_type_id_seq', 67, true);
 +SELECT pg_catalog.setval('django_content_type_id_seq', 68, true);


  --
 }}}

 and another diff between the second and the third time:
 http://linkode.org/rX21iFzHICntF4ergjEcW5

 {{{
 --- chap-migration-test-after-2nd-migrate.sql   2014-09-18
 09:32:17.148672191 -0300
 +++ chap-migration-test-after-3rd-migrate.sql   2014-09-18
 09:37:38.948663938 -0300
 @@ -2908,7 +2908,7 @@
  202Can add group object permission 67  add_groupobjectpermission
  203Can change group object permission  67
 change_groupobjectpermission
  204Can delete group object permission  67
 delete_groupobjectpermission
 -205Can edit core non-model settings68  can_edit__settings
 +206Can edit core non-model settings69  can_edit__settings
  \.


 @@ -2916,7 +2916,7 @@
  -- Name: auth_permission_id_seq; Type: SEQUENCE SET; Schema: public;
 Owner: postgres
  --

 -SELECT pg_catalog.setval('auth_permission_id_seq', 205, true);
 +SELECT pg_catalog.setval('auth_permission_id_seq', 206, true);


  --
 @@ -3329,7 +3329,7 @@
  65

[django/django] e008a1: Fixed #23443 -- Corrected erroneous FieldError mes...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e008a10c2ffef7d64100bcbe83ef2c5f4b1b2168
  
https://github.com/django/django/commit/e008a10c2ffef7d64100bcbe83ef2c5f4b1b2168
  Author: Thomas Chaumeny 
  Date:   2014-09-19 (Fri, 19 Sep 2014)

  Changed paths:
M django/db/models/sql/query.py
M tests/queries/tests.py

  Log Message:
  ---
  Fixed #23443 -- Corrected erroneous FieldError message.

Thanks Tim Graham for the review.


-- 
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/541b1e382ba65_67953fbd2a3132c029738%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23443: Inconsistent FieldError message under some circumstances

[Django]

#23443: Inconsistent FieldError message under some circumstances
-+-
 Reporter:  tchaumeny|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Loic Bistuer ):

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


Comment:

 In [changeset:"e008a10c2ffef7d64100bcbe83ef2c5f4b1b2168"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e008a10c2ffef7d64100bcbe83ef2c5f4b1b2168"
 Fixed #23443 -- Corrected erroneous FieldError message.

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

Re: [Django] #23514: Prevent database connection at PostGISOperations init time

[Django]

#23514: Prevent database connection at PostGISOperations init time
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  GIS  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"abc11b0a33fd823ad341ab2cc113c73545eb61e6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="abc11b0a33fd823ad341ab2cc113c73545eb61e6"
 Fixed #23514 -- Prevented queries in PostGISOperations init

 Thanks Mattia Procopio for the report.
 }}}

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

[django/django] abc11b: Fixed #23514 -- Prevented queries in PostGISOperat...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: abc11b0a33fd823ad341ab2cc113c73545eb61e6
  
https://github.com/django/django/commit/abc11b0a33fd823ad341ab2cc113c73545eb61e6
  Author: Claude Paroz 
  Date:   2014-09-18 (Thu, 18 Sep 2014)

  Changed paths:
M django/contrib/gis/db/backends/postgis/operations.py
M tests/backends/tests.py

  Log Message:
  ---
  Fixed #23514 -- Prevented queries in PostGISOperations init

Thanks Mattia Procopio for the report.


-- 
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/541b1ddd7512b_69523faa95b2729c394b3%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] 4dcfac: Fixed string length check in LayerMapping

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4dcfacb5b92dc06c4a351119cf501d842d46d192
  
https://github.com/django/django/commit/4dcfacb5b92dc06c4a351119cf501d842d46d192
  Author: Claude Paroz 
  Date:   2014-09-18 (Thu, 18 Sep 2014)

  Changed paths:
M django/contrib/gis/tests/layermap/models.py
M django/contrib/gis/tests/layermap/tests.py
M django/contrib/gis/utils/layermapping.py

  Log Message:
  ---
  Fixed string length check in LayerMapping


-- 
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/541b1d618a974_5a283fc2643952b87453c%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23503: renaming model with self-referential ManyToManyField breaks DB schema

[Django]

#23503: renaming model with self-referential ManyToManyField breaks DB schema
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 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 timgraham):

 * severity:  Normal => Release blocker
 * 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/068.77d13ade3bb8199e25467b19e043c3a0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23518: Subquery does not respect explicit __exact

[Django]

#23518: Subquery does not respect explicit __exact
-+-
 Reporter:  john-parton  |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Database layer   |Version:  1.7
  (models, ORM)  |   Keywords:  subquery subselect
 Severity:  Normal   |  exact
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 I think it should be possible to use a subquery as an expression with
 `__exact`.

 It appears that when you perform a subquery, the ORM includes an
 **implicit** `__in`. This is fine, because I'm sure that covers most use
 cases, but if you try to provide an **explicit** `__exact`, the ORM
 disregards it.


 {{{#!python
 # models.py
 from django.db import models

 class Child(models.Model):
 parent = models.ForeignKey('Parent')

 class Parent(models.Model):
 slug = models.SlugField(unique=True)
 }}}

 {{{#!python
 In [1]: from model_test.models import Child, Parent

 In [2]: parent = Parent(slug='test')

 In [3]: parent.save()

 In [4]: child = Child(parent=parent)

 In [5]: child.save()

 In [6]: children =
 Child.objects.filter(parent_id=Parent.objects.filter(slug='test'))

 In [7]: print(children.query)
 SELECT "model_test_child"."id", "model_test_child"."parent_id" FROM
 "model_test_child" WHERE "model_test_child"."parent_id" IN (SELECT U0."id"
 FROM "model_test_parent" U0 WHERE U0."slug" = test)

 In [8]: children =
 Child.objects.filter(parent_id__exact=Parent.objects.filter(slug='test'))

 In [9]: print(children.query)
 SELECT "model_test_child"."id", "model_test_child"."parent_id" FROM
 "model_test_child" WHERE "model_test_child"."parent_id" IN (SELECT U0."id"
 FROM "model_test_parent" U0 WHERE U0."slug" = test)
 }}}


 The expected output of the 9th command is:

 {{{#!sql
 SELECT "model_test_child"."id", "model_test_child"."parent_id" FROM
 "model_test_child" WHERE "model_test_child"."parent_id" = (SELECT U0."id"
 FROM "model_test_parent" U0 WHERE U0."slug" = 'test');
 }}}

 Obviously using `__exact` isn't always possible, but because `Parent` has
 a unique slug, we can guarantee that the subquery returns one or zero
 rows. Alternative, we could have added a `LIMIT 1` (or a `[:1]` with the
 ORM) to ensure that it has exactly one or zero rows.

 The most simple way to do error handling would to just wrap the
 `ProgrammingError: more than one row returned by a subquery used as an
 expression` which would get raised by the connection.

 At the very least, shouldn't the `__exact` transform raise some error or
 issue some warning that it does nothing?

 Thoughts?

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

Re: [Django] #23514: Prevent database connection at PostGISOperations init time

[Django]

#23514: Prevent database connection at PostGISOperations init time
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  GIS  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|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/065.fa8c979d396f696649fd2b3dab410147%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 7fc131: Removed unnecessary order_by() from a GIS test tha...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 7fc13178d6b0e4b365c43991a6661c6b2118a3a9
  
https://github.com/django/django/commit/7fc13178d6b0e4b365c43991a6661c6b2118a3a9
  Author: Tim Graham 
  Date:   2014-09-18 (Thu, 18 Sep 2014)

  Changed paths:
M django/contrib/gis/tests/layermap/tests.py

  Log Message:
  ---
  Removed unnecessary order_by() from a GIS test that crashed Oracle.

Oracle cannot order_by() a TextField; refs #23504.


-- 
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/541b0bf03da06_5de73f8de67bf29c884f%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23504: Oracle GIS test failures

[Django]

#23504: Oracle GIS test failures
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  new
Component:  GIS|  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 Tim Graham ):

 In [changeset:"7fc13178d6b0e4b365c43991a6661c6b2118a3a9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7fc13178d6b0e4b365c43991a6661c6b2118a3a9"
 Removed unnecessary order_by() from a GIS test that crashed Oracle.

 Oracle cannot order_by() a TextField; refs #23504.
 }}}

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

Re: [Django] #23242: slow date_hierarchy on a big tables

[Django]

#23242: slow date_hierarchy on a big tables
-+-
 Reporter:  meteozond|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  date_hierarchy   |  Unreviewed
  datetimes dates|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by timgraham):

 @herve, do you have ideas for how to improve the situation? Absent that, I
 don't see a reason to keep this ticket open besides maybe documenting
 "Don't use `date_hierarchy` if you have millions of entries."

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

Re: [Django] #23514: Prevent database connection at PostGISOperations init time

[Django]

#23514: Prevent database connection at PostGISOperations init time
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by claudep):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #23242: slow date_hierarchy on a big tables

[Django]

#23242: slow date_hierarchy on a big tables
-+-
 Reporter:  meteozond|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  date_hierarchy   |  Unreviewed
  datetimes dates|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by herve):

 * status:  closed => new
 * cc: herve (added)
 * resolution:  needsinfo =>


Comment:

 Here is an example of such a request:

 {{{#!sql
 SELECT DISTINCT DATE_TRUNC('day', "messages_message"."sent_at" AT TIME
 ZONE E'Europe/Paris') FROM "messages_message" WHERE (EXTRACT('month' FROM
 "messages_message"."sent_at" AT TIME ZONE E'Europe/Paris') = 9 AND
 "messages_message"."sent_at" BETWEEN
 '2014-01-01T00:00:00+01:00'::timestamptz and
 '2014-12-31T23:59:59.99+01:00'::timestamptz AND
 "messages_message"."sent_at" IS NOT NULL) ORDER BY 1 ASC
 }}}

 The explain/analyze on ~6 million entries:

 {{{
  Sort  (cost=62488.59..62488.60 rows=1 width=8) (actual
 time=18791.784..18791.784 rows=1 loops=1)
Sort Key: (date_trunc('day'::text, timezone('Europe/Paris'::text,
 sent_at)))
Sort Method: quicksort  Memory: 25kB
->  HashAggregate  (cost=62488.57..62488.58 rows=1 width=8) (actual
 time=18791.465..18791.466 rows=1 loops=1)
  ->  Bitmap Heap Scan on messages_message  (cost=856.42..62488.18
 rows=153 width=8) (actual time=1276.004..17066.794 rows=6135296 loops=1)
Recheck Cond: ((sent_at >= '2014-01-01
 00:00:00+01'::timestamp with time zone) AND (sent_at <= '2014-12-31
 23:59:59.99+01'::timestamp with time zone) AND (sent_at IS NOT NULL))
Filter: (date_part('month'::text,
 timezone('Europe/Paris'::text, sent_at)) = 9::double precision)
->  Bitmap Index Scan on messages_message_sent_at_id_idx
 (cost=0.00..856.38 rows=30655 width=0) (actual time=1274.039..1274.039
 rows=6136069 loops=1)
  Index Cond: ((sent_at >= '2014-01-01
 00:00:00+01'::timestamp with time zone) AND (sent_at <= '2014-12-31
 23:59:59.99+01'::timestamp with time zone) AND (sent_at IS NOT NULL))
  Total runtime: 18791.933 ms
 }}}

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

Re: [Django] #21648: Deprecate "is_admin_site" option of auth.views.password_reset()

[Django]

#21648: Deprecate "is_admin_site" option of auth.views.password_reset()
--+
 Reporter:  brain@…   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.auth  |  Version:  master
 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 googol7):

 Good question. I think that updating to the sites framework would be a lot
 of overhead for us as we just provide a branded site based on the URL. I
 don't know if this is a common setup but probably its worth thinking about
 why the domain defined for a site shall be used for the password reset
 link in the email and if it would be sufficient to just use
 request.get_host() Because if the user visits the domain of the site
 framework it's the current domain of the current request anyway.

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

Re: [Django] #23488: Missing get_username in AnonymousUser

[Django]

#23488: Missing get_username in AnonymousUser
--+
 Reporter:  dbaty |Owner:  dbaty
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ad491ecc6e20569a4f5c30a671a935f5c766a295"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ad491ecc6e20569a4f5c30a671a935f5c766a295"
 Fixed #23488 -- Added AnonymousUser.get_username().
 }}}

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

[django/django] ad491e: Fixed #23488 -- Added AnonymousUser.get_username()...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ad491ecc6e20569a4f5c30a671a935f5c766a295
  
https://github.com/django/django/commit/ad491ecc6e20569a4f5c30a671a935f5c766a295
  Author: Damien Baty 
  Date:   2014-09-18 (Thu, 18 Sep 2014)

  Changed paths:
M django/contrib/auth/models.py
M django/contrib/auth/tests/test_basic.py
M docs/ref/contrib/auth.txt

  Log Message:
  ---
  Fixed #23488 -- Added AnonymousUser.get_username().


-- 
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/541af0fa3278a_189e3faa1b0152c03382f%40hookshot-fe3-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[Django] #23517: Collect static files in parallel

[Django]

#23517: Collect static files in parallel
-+
 Reporter:  thenewguy|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  contrib.staticfiles  |Version:  1.7
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 It would really speed up collectstatic on remote storages to copy files in
 parallel.

 It shouldn't be too complicated to refactor the command to work with
 multiprocessing.

 I am submitting the ticket as a reminder to myself when I have a free
 moment.  Would this be accepted into Django?

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

[django/django] 8facb0: Improved GIS migration test cleanup; refs #23504.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 8facb02faf1880187888b26724760865547b05b0
  
https://github.com/django/django/commit/8facb02faf1880187888b26724760865547b05b0
  Author: Tim Graham 
  Date:   2014-09-18 (Thu, 18 Sep 2014)

  Changed paths:
M django/contrib/gis/tests/gis_migrations/test_operations.py

  Log Message:
  ---
  Improved GIS migration test cleanup; refs #23504.


-- 
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/541ad79552475_689c3f88ba1572a09404e%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23504: Oracle GIS test failures

[Django]

#23504: Oracle GIS test failures
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  new
Component:  GIS|  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 Tim Graham ):

 In [changeset:"8facb02faf1880187888b26724760865547b05b0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8facb02faf1880187888b26724760865547b05b0"
 Improved GIS migration test cleanup; refs #23504.
 }}}

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

Re: [Django] #23516: ifchanged no longer works within an included template

[Django]

#23516: ifchanged no longer works within an included template
-+
 Reporter:  dracos   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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 bmispelon):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Hi,

 I can reproduce this regression and traced it back to
 e2f06226ea4a38377cdb69f2f5768e4e00c2d88e as you suspected.

 Not sure if we can fix the code or if we should document the regression
 but I'm moving the ticket forward either way.

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

Re: [Django] #23501: remove/add fields programatically in modelform fails in admin

[Django]

#23501: remove/add fields programatically in modelform fails in admin
---+
 Reporter:  hadisunyoto|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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
---+

Comment (by timgraham):

 You should be able to keep the `del` logic, as long as you also use
 `get_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/069.7a34b5739d4edbeebde9c1a4bf3af6a9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17656: collectstatic should not require a database

[Django]

#17656: collectstatic should not require a database
-+-
 Reporter:  jcspray@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   |  worksforme
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

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

[django/django] 33e817: Added feature flag for geometry_field_introspectio...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 33e817a6d8b163aa6e8a2fb15d7269d1ecbbcf59
  
https://github.com/django/django/commit/33e817a6d8b163aa6e8a2fb15d7269d1ecbbcf59
  Author: Tim Graham 
  Date:   2014-09-18 (Thu, 18 Sep 2014)

  Changed paths:
M django/contrib/gis/db/backends/base.py
M django/contrib/gis/db/backends/oracle/base.py
M django/contrib/gis/tests/inspectapp/tests.py

  Log Message:
  ---
  Added feature flag for geometry_field_introspection; refs #22632 and #23504.


-- 
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/541ac38f5d951_494f3fb58bf3d2b885df%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23504: Oracle GIS test failures

[Django]

#23504: Oracle GIS test failures
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  new
Component:  GIS|  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 Tim Graham ):

 In [changeset:"33e817a6d8b163aa6e8a2fb15d7269d1ecbbcf59"]:
 {{{
 #!CommitTicketReference repository=""
 revision="33e817a6d8b163aa6e8a2fb15d7269d1ecbbcf59"
 Added feature flag for geometry_field_introspection; refs #22632 and
 #23504.
 }}}

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

Re: [Django] #22632: Spatial backend tests uses hardcoded set of backends

[Django]

#22632: Spatial backend tests uses hardcoded set of backends
--+
 Reporter:  jtiai |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  gis database testing  | 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:"33e817a6d8b163aa6e8a2fb15d7269d1ecbbcf59"]:
 {{{
 #!CommitTicketReference repository=""
 revision="33e817a6d8b163aa6e8a2fb15d7269d1ecbbcf59"
 Added feature flag for geometry_field_introspection; refs #22632 and
 #23504.
 }}}

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

Re: [Django] #23504: Oracle GIS test failures

[Django]

#23504: Oracle GIS test failures
---+-
 Reporter:  timgraham  |Owner:  timgraham
 Type:  Bug|   Status:  new
Component:  GIS|  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 Tim Graham ):

 In [changeset:"6c1a0581abd9cf21fa37c6c9e9937986da45005c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6c1a0581abd9cf21fa37c6c9e9937986da45005c"
 Added a feature flag for add_srs_entry support; refs #22632 and #23504.
 }}}

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

Re: [Django] #22632: Spatial backend tests uses hardcoded set of backends

[Django]

#22632: Spatial backend tests uses hardcoded set of backends
--+
 Reporter:  jtiai |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  GIS   |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  gis database testing  | 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:"6c1a0581abd9cf21fa37c6c9e9937986da45005c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6c1a0581abd9cf21fa37c6c9e9937986da45005c"
 Added a feature flag for add_srs_entry support; refs #22632 and #23504.
 }}}

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

[django/django] 6c1a05: Added a feature flag for add_srs_entry support; re...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6c1a0581abd9cf21fa37c6c9e9937986da45005c
  
https://github.com/django/django/commit/6c1a0581abd9cf21fa37c6c9e9937986da45005c
  Author: Tim Graham 
  Date:   2014-09-18 (Thu, 18 Sep 2014)

  Changed paths:
M django/contrib/gis/db/backends/base.py
M django/contrib/gis/db/backends/mysql/base.py
M django/contrib/gis/db/backends/oracle/base.py
M django/contrib/gis/tests/test_spatialrefsys.py
M django/contrib/gis/utils/srs.py

  Log Message:
  ---
  Added a feature flag for add_srs_entry support; refs #22632 and #23504.


-- 
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/541ac2505092b_5e4c3fb79d9d12c073696%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[Django] #23516: ifchanged no longer works within an included template

[Django]

#23516: ifchanged no longer works within an included template
-+
 Reporter:  dracos   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Template system  |Version:  1.7
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 If you use ifchanged within an included template, whereas in 1.6 and
 previous this worked fine, in 1.7 ifchanged no longer appears to remember
 its stored state between iterations and so is always true.

 I have uploaded a minimal test project to show this at
 https://github.com/dracos/broken-ifchanged with the Travis test results
 for 1.6 (pass) and 1.7 (fail) at https://travis-ci.org/dracos/broken-
 ifchanged/builds/35620470

 I assume this is presumably related to the recursion changes mentioned in
 the Django 1.7 release notes, but if so it's not totally clear and so I
 thought I'd report this so at least the documentation could perhaps be
 changed to mention this issue and that you can't use ifchanged inside an
 include inside a loop.

 I'm not sure what we can do now to get our code (full code Travis with 1.7
 failure can be seen at https://travis-
 ci.org/mysociety/sayit/builds/35613315 ) working on 1.7 - we don't want to
 inline the inner template, it's quite large and used in multiple places.

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

Re: [Django] #23514: Prevent database connection at PostGISOperations init time

[Django]

#23514: Prevent database connection at PostGISOperations init time
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  master
 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
--+

Old description:

> Currently, `PostGISOperations` does query the database during its init
> time (to check the spatial version). This should be avoided if possible
> (see use case in #17656), and should be doable by transforming some
> variables into properties.

New description:

 Currently, `PostGISOperations` does query the database during its init
 time (to check the spatial version). This should be avoided if possible
 (see use case in #17656), and should be doable by transforming some
 variables into properties.


 {{{
 Traceback (most recent call last):
   File "manage.py", line 12, in 
 execute_from_command_line(sys.argv)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 385, in
 execute_from_command_line
 utility.execute()
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 354, in execute
 django.setup()
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/__init__.py", line 21, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/apps/registry.py", line 108, in populate
 app_config.import_models(all_models)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/apps/config.py", line 197, in import_models
 self.models_module = import_module(models_module_name)
   File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
 import_module
 __import__(name)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/contrib/auth/models.py", line 40, in 
 class Permission(models.Model):
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/db/models/base.py", line 125, in __new__
 new_class.add_to_class('_meta', Options(meta, **kwargs))
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/db/models/base.py", line 300, in add_to_class
 value.contribute_to_class(cls, name)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/db/models/options.py", line 166, in contribute_to_class
 self.db_table = truncate_name(self.db_table,
 connection.ops.max_name_length())
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/db/__init__.py", line 40, in __getattr__
 return getattr(connections[DEFAULT_DB_ALIAS], item)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/db/utils.py", line 243, in __getitem__
 conn = backend.DatabaseWrapper(db, alias)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/contrib/gis/db/backends/postgis/base.py", line 14, in
 __init__
 self.ops = PostGISOperations(self)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/contrib/gis/db/backends/postgis/operations.py", line 166,
 in __init__
 if self.spatial_version < (1, 3, 4):
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/utils/functional.py", line 55, in __get__
 res = instance.__dict__[self.func.__name__] = self.func(instance)
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/contrib/gis/db/backends/postgis/operations.py", line 260,
 in spatial_version
 vtup = self.postgis_version_tuple()
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/contrib/gis/db/backends/postgis/operations.py", line 434,
 in postgis_version_tuple
 version = self.postgis_lib_version()
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/contrib/gis/db/backends/postgis/operations.py", line 414,
 in postgis_lib_version
 return self._get_postgis_func('postgis_lib_version')
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/contrib/gis/db/backends/postgis/operations.py", line 404,
 in _get_postgis_func
 with self.connection.temporary_connection() as cursor:
   File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__
 return self.gen.next()
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/db/backends/__init__.py", line 543, in
 temporary_connection
 cursor = self.cursor()
   File "/home/matt/repos/uwncom/lib/python2.7/site-
 packages/django/db/back

Re: [Django] #17656: collectstatic should not require a database

[Django]

#17656: collectstatic should not require a database
-+
 Reporter:  jcspray@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  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 MattBlack85):

 claudep, you're right, if I switch to postgres I can't reproduce this
 behaviour. This can be then closed, I'm going to add the traceback to the
 new 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/075.39c6e5bbbc08e87d4a2c9b846094a57b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22479: Support byte range requests in django.views.static.serve

[Django]

#22479: Support byte range requests in django.views.static.serve
---+
 Reporter:  slurms |Owner:  slurms
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by alper):

 I would settle for a separate package that does this, but as it stands now
 for trying things out having to setup nginx on my local machine is a bit
 too much work.

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

Re: [Django] #17522: ModelAdmin.ordering validation too strict

[Django]

#17522: ModelAdmin.ordering validation too strict
-+-
 Reporter:  sebastian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, validation,   | Triage Stage:  Accepted
  ordering, strict   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by marfire):

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

[Django] #23515: AUTH_USER_MODEL and admin.E108

[Django]

#23515: AUTH_USER_MODEL and admin.E108
---+---
 Reporter:  fizista|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.7
 Severity:  Normal |   Keywords:  admin AUTH_USER_MODEL
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 Description of the problem:
 In the administration panel you can not use relationships with the
 {{{__}}} lookup.

 I receive the following error:
 {{{
 : (admin.E108) The value of
 'list_display[1]' refers to 'user__first_name', which is not a callable,
 an attribute of 'UserProfileAdmin', or an attribute or method on
 'accounts.UserProfile'
 }}}

 Sample code that generates this error:

 {{{#!python

 class UserProfile(models.Model):

 user = models.OneToOneField(settings.AUTH_USER_MODEL,
 primary_key=True)

 class UserProfileAdmin(admin.ModelAdmin):

 list_display = (
 'user__id', 'user__first_name', 'user__last_name', 'user__email',)

 }}}

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

Re: [Django] #23488: Missing get_username in AnonymousUser

[Django]

#23488: Missing get_username in AnonymousUser
--+
 Reporter:  dbaty |Owner:  dbaty
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by dbaty):

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


Comment:

 How, seeing the `tests/` directory at the root, I missed the tests in
 `django/contrib/auth/tests`...

 A PR is here: https://github.com/django/django/pull/3235 that has tests
 and 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/063.9509f74433d65ff3e85a570abb60012c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23514: Prevent database connection at PostGISOperations init time

[Django]

#23514: Prevent database connection at PostGISOperations init time
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  master
 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
--+
Description changed by claudep:

Old description:

> Currently, `PostGISOperations` does query the database during its init
> time (to check the spatial version). This should be avoided if possible
> (see use case in #17656), and should be doable by transforming some
> variables tests into properties.

New description:

 Currently, `PostGISOperations` does query the database during its init
 time (to check the spatial version). This should be avoided if possible
 (see use case in #17656), and should be doable by transforming some
 variables into properties.

--

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

Re: [Django] #17656: collectstatic should not require a database

[Django]

#17656: collectstatic should not require a database
-+
 Reporter:  jcspray@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  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 claudep):

 MattBlack85, the traceback shows that this is a PostGIS specific issue.
 I've created a new ticket to track that issue: #23514.
 Now it is possible that this happens with a plain PostgreSQL connection,
 too, but it would be worth a try.

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

[Django] #23514: Prevent database connection at PostGISOperations init time

[Django]

#23514: Prevent database connection at PostGISOperations init time
+
   Reporter:  claudep   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 Currently, `PostGISOperations` does query the database during its init
 time (to check the spatial version). This should be avoided if possible
 (see use case in #17656), and should be doable by transforming some
 variables tests into properties.

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