date:20160217

Re: [Django] #26232: i18n unit test fails on xgettext in /usr/local/bin

2016-02-17 Thread Django

#26232: i18n unit test fails on xgettext in /usr/local/bin
--+
 Reporter:  jeroenp   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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):

 The fix for #25925 was maybe not the best one. We may have copy
 `os.environ` and only override the `LANG` 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/065.5bb10f35ac81fd41fc38ba9e95152272%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26232: i18n unit test fails on xgettext in /usr/local/bin

2016-02-17 Thread Django

#26232: i18n unit test fails on xgettext in /usr/local/bin
--+
 Reporter:  jeroenp   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  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
--+
Changes (by timgraham):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * component:  Testing framework => Internationalization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I guess something like 1d9fc5caa947ff4ee72180185e91a9a145171712 might work
 (with `PATH` instead of `PYTHONPATH`). Can you try to develop a patch that
 works for you?

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

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

Re: [Django] #25143: ArrayField should implement from_db_value()

2016-02-17 Thread Django

#25143: ArrayField should implement from_db_value()
--+
 Reporter:  Odahi |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1
 * stage:  Ready for checkin => 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/063.f3bcdd75b2dcdad5b902ceac92c5e9b2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #5793: Allow custom attributes in Meta classes

2016-02-17 Thread Django

#5793: Allow custom attributes in Meta classes
-+-
 Reporter:  eikke@…  |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:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * component:  Metasystem => Database layer (models, ORM)
 * easy:  1 => 0


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

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

Re: [Django] #5793: Allow custom attributes in Meta classes

2016-02-17 Thread Django

#5793: Allow custom attributes in Meta classes
-+
 Reporter:  eikke@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Metasystem   |  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
-+
Changes (by litchfield):

 * cc: litchfield (removed)
 * easy:  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/073.18996ea78b179353e0a941d87f74f22d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #5793: Allow custom attributes in Meta classes

2016-02-17 Thread Django

#5793: Allow custom attributes in Meta classes
-+
 Reporter:  eikke@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Metasystem   |  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
-+
Changes (by litchfield):

 * cc: litchfield (added)


Comment:

 +1 - it's kinda daft to encourage the ORM to be extendable, while at the
 same time restricting what Meta options we're allowed

 Why not just move DEFAULT_NAMES into the Model class? problem solved, zero
 breakage.

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

Re: [Django] #26229: Missing check for list_editable in admin

2016-02-17 Thread Django

#26229: Missing check for list_editable in admin
---+
 Reporter:  alasdairnicol  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by alasdairnicol):

 * has_patch:  0 => 1


Comment:

 I've opened a pull request
 https://github.com/django/django/pull/6156/files

 The two old unit tests from #22792 still pass following my changes, and I
 have added an addition test. However, I found it a tricky problem to get
 my head around, so I'm not 100% certain I got it correct. I've added
 comments to the pull request to explain my reasoning.

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

[Django] #26232: i18n unit test fails on xgettext in /usr/local/bin

2016-02-17 Thread Django

#26232: i18n unit test fails on xgettext in /usr/local/bin
---+
 Reporter:  jeroenp|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The test_compilation unit test sets a very minimalist environment so that
 the unit test fails to find xgettext in /usr/local/bin (homebrew on mac,
 anyone?).

 {{{
 ==
 [51/291]
 ERROR: test_msgfmt_error_including_non_ascii
 (i18n.test_compilation.CompilationErrorHandling$
 --
 Traceback (most recent call last):
   File
 
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.
 5/unittest/case.py", line 58, in testPartExecutor
 yield
   File
 
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.
 5/unittest/case.py", line 600, in run
 testMethod()
   File
 
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.
 5/unittest/mock.py", line 1157, in patched
 return func(*args, **keywargs)
   File "/Users/jeroenp/projects/django/tests/i18n/test_compilation.py",
 line 184, in test_msg
 fmt_error_including_non_ascii
 if cmd.gettext_version < (0, 18, 3):

 [snip]

   File "/Users/jeroenp/projects/django/django/core/management/utils.py",
 line 21, in popen_wr
 apper
 p = Popen(args, shell=False, stdout=PIPE, stderr=PIPE,
 close_fds=os.name != 'nt')
   File "/Users/jeroenp/projects/django/tests/i18n/test_compilation.py",
 line 171, in 
 lambda *args, **kwargs: Popen(*args, env={'LANG': 'C'}, **kwargs))
   File
 
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.
 5/subprocess.py", line 950, in __init__
 restore_signals, start_new_session)
   File
 
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.
 5/subprocess.py", line 1544, in _execute_child
raise child_exception_type(errno_num, err_msg)
 django.core.management.base.CommandError: Error executing xgettext: No
 such file or directory
 : 'xgettext'

 --
 Ran 10518 tests in 97.610s
 }}}


 Verifying with a stripped environment in a shell:

 {{{
 (django-env-py3) tests$ env -i LANG=C xgettext
 env: xgettext: No such file or directory
 (django-env-py3) tests$ which xgettext
 /usr/local/bin/xgettext
 (django-env-py3) tests$ env -i LANG=C  PATH=/usr/local/bin:/usr/bin:/bin
 xgettext
 xgettext: no input file given
 Try 'xgettext --help' for more information.
 }}}

 Adding a hardcoded PATH to the env argument to Popen in
 test_compilation.py fixes this, but I'm assuming that's not the way to go
 forward.

 See #25925

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

Re: [Django] #26225: Coalesce Multiple Calls to order_by with Same Arguments

2016-02-17 Thread Django

#26225: Coalesce Multiple Calls to order_by with Same Arguments
-+-
 Reporter:  cancan101|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 cancan101):

 Replying to [comment:5 shaib]:

 Related might be this SO post which is incorrectly answered:
 http://stackoverflow.com/questions/18835961/django-how-to-find-which-
 fields-a-queryset-is-being-ordered-by/18852765

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

Re: [Django] #26225: Coalesce Multiple Calls to order_by with Same Arguments

2016-02-17 Thread Django

#26225: Coalesce Multiple Calls to order_by with Same Arguments
-+-
 Reporter:  cancan101|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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):

 * cc: shaib (added)


Comment:

 Replying to [comment:2 mjtamlyn]:
 > [Y]ou could add this kind of behaviour to a custom queryset class, but
 you would be inspecting private properties of the underlying query object
 to get what you want.

 Perhaps we should consider making such properties public? It could help
 with making querysets more composable and reusable, I think.

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

Re: [Django] #25687: Document how database backends should monkey patch functions (was: Document how backends should monkey patch expressions)

2016-02-17 Thread Django

#25687: Document how database backends should monkey patch functions
-+-
 Reporter:  jarshwah |Owner:
 Type:   |  kristofclaes
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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 timgraham):

 (leaving the documentation of how to patch expressions to #25759)

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

Re: [Django] #26219: Cannot filter by DecimalField in RawQuery

2016-02-17 Thread Django

#26219: Cannot filter by DecimalField in RawQuery
-+-
 Reporter:  jirek|Owner:  akki
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  DecimalField | Triage Stage:  Accepted
  RawQuery   |
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:"0d2b97ca18b576d1bbff2ccb089527e36d99eaf9" 0d2b97ca]:
 {{{
 #!CommitTicketReference repository=""
 revision="0d2b97ca18b576d1bbff2ccb089527e36d99eaf9"
 [1.9.x] Fixed #26219 -- Fixed crash when filtering by Decimal in RawQuery.

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

Re: [Django] #26219: Cannot filter by DecimalField in RawQuery

2016-02-17 Thread Django

#26219: Cannot filter by DecimalField in RawQuery
-+-
 Reporter:  jirek|Owner:  akki
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  DecimalField | Triage Stage:  Accepted
  RawQuery   |
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:"fdccc02576ae5a524338f65e629948604d80b4c8" fdccc025]:
 {{{
 #!CommitTicketReference repository=""
 revision="fdccc02576ae5a524338f65e629948604d80b4c8"
 Fixed #26219 -- Fixed crash when filtering by Decimal in RawQuery.
 }}}

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

Re: [Django] #25687: Document how backends should monkey patch expressions

2016-02-17 Thread Django

#25687: Document how backends should monkey patch expressions
-+-
 Reporter:  jarshwah |Owner:
 Type:   |  kristofclaes
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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 Tim Graham ):

 In [changeset:"477b82cf8a7eefac98ff4f5afb4754727f4b0004" 477b82cf]:
 {{{
 #!CommitTicketReference repository=""
 revision="477b82cf8a7eefac98ff4f5afb4754727f4b0004"
 [1.9.x] Fixed #25687 -- Documented how to add database function support to
 third-party backends.

 Thanks Kristof Claes for the initial patch.

 Backport of 88034c9938d92193d2104ecfe77999c69301dcc1 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/066.58dc7ca2d86fd4bcffe6695e8a6ce5af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25687: Document how backends should monkey patch expressions

2016-02-17 Thread Django

#25687: Document how backends should monkey patch expressions
-+-
 Reporter:  jarshwah |Owner:
 Type:   |  kristofclaes
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"88034c9938d92193d2104ecfe77999c69301dcc1" 88034c99]:
 {{{
 #!CommitTicketReference repository=""
 revision="88034c9938d92193d2104ecfe77999c69301dcc1"
 Fixed #25687 -- Documented how to add database function support to third-
 party backends.

 Thanks Kristof Claes for the initial patch.
 }}}

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

Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

2016-02-17 Thread Django

#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
---+
 Reporter:  davidszotten   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.8
 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
---+

Comment (by timgraham):

 Find a colleague to review the patch.

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

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

Re: [Django] #20932: Issues with model Manager and inheritance.

2016-02-17 Thread Django

Comment (by carljm):

I like the proposal loic84 outlined (and mjtamlyn further explained as
option 1); given the longstanding discrepancy between the docs and the
actual behavior, I think that's a reasonable level of backwards-
incompatibility (if well documented) to achieve more predictable behavior.

I think eliminating `_default_manager` is a much bigger backwards-
incompatibility for the reason loic84 mentioned, and I don't see that it
really gains us much. To me "normal inheritance plus default `objects`
added if no other manager" is fine.

The other aspect here is that as long as we have to re-instantiate
managers at every inheritance level in order to re-bind them to the
correct model class, none of this can really fairly be described as
"normal MRO" because it's a different instance at every level, which is
certainly not how attribute resolution via the MRO normally behaves. I
discussed briefly with loic84 in IRC the option of having managers
actually assign a descriptor to the class that would bind a manager
instance to the correct model class on access, to avoid this need for re-
binding in advance at every inheritance level. But that's definitely a
bigger change and would need exploration to see if it's feasible.

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

Re: [Django] #25251: Inconsistent availability of data migrations in TransactionTestCase when using --keepdb

2016-02-17 Thread Django

#25251: Inconsistent availability of data migrations in TransactionTestCase when
using --keepdb
---+
 Reporter:  davidszotten   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.8
 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
---+

Comment (by romgar):

 Can I do something else to help on that issue ?

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

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

Re: [Django] #26231: Hint for non-staff users on admin page refers wrong attribute for username.

2016-02-17 Thread Django

#26231: Hint for non-staff users on admin page refers wrong attribute for 
username.
---+
 Reporter:  sjoerdjob  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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
---+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 1
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/6155 PR] needs 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/067.1b26c9ca443fdb61c472b918c8f2e38a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26229: Missing check for list_editable in admin

2016-02-17 Thread Django

#26229: Missing check for list_editable in admin
---+
 Reporter:  alasdairnicol  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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
---+
Changes (by timgraham):

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

Re: [Django] #19353: Make it easier to extend UserCreationForm for custom user models

2016-02-17 Thread Django

#19353: Make it easier to extend UserCreationForm for custom user models
-+-
 Reporter:  bmispelon|Owner:
 |  berkerpeksag
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:
 |  1.5-alpha-1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  UserCreationForm | Triage Stage:  Accepted
  AUTH_USER_MODEL|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 If there are any further improvements, let's open a new ticket. 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/067.b4ea251fbd4169e2e01d91b79dfe5831%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #19353: Make it easier to extend UserCreationForm for custom user models

2016-02-17 Thread Django

#19353: Make it easier to extend UserCreationForm for custom user models
-+-
 Reporter:  bmispelon|Owner:
 |  berkerpeksag
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:
 |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  UserCreationForm | Triage Stage:  Accepted
  AUTH_USER_MODEL|
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:"f78892f2de1e986f00d23581dc006e90e26abd8f" f78892f2]:
 {{{
 #!CommitTicketReference repository=""
 revision="f78892f2de1e986f00d23581dc006e90e26abd8f"
 [1.9.x] Refs #19353 -- Added tests for using custom user models with
 built-in auth forms.

 Also updated topics/auth/customizing.txt to reflect that subclasses of
 UserCreationForm and UserChangeForm can be used with custom user models.

 Thanks Baptiste Mispelon for the initial documentation.

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

Re: [Django] #19353: Make it easier to extend UserCreationForm for custom user models

2016-02-17 Thread Django

#19353: Make it easier to extend UserCreationForm for custom user models
-+-
 Reporter:  bmispelon|Owner:
 |  berkerpeksag
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:
 |  1.5-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:  UserCreationForm | Triage Stage:  Accepted
  AUTH_USER_MODEL|
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:"f0425c72601f466c6a71518749c6d15b94945514" f0425c7]:
 {{{
 #!CommitTicketReference repository=""
 revision="f0425c72601f466c6a71518749c6d15b94945514"
 Refs #19353 -- Added tests for using custom user models with built-in auth
 forms.

 Also updated topics/auth/customizing.txt to reflect that subclasses of
 UserCreationForm and UserChangeForm can be used with custom user models.

 Thanks Baptiste Mispelon for the initial 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/067.ffa524e654e475112a15eeb618f3cb40%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #26231: Hint for non-staff users on admin page refers wrong attribute for username.

2016-02-17 Thread Django

#26231: Hint for non-staff users on admin page refers wrong attribute for 
username.
---+
 Reporter:  sjoerdjob  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 In commit 635ffc3c37d58eb96ae17d5389dd50bf635413c6 a block was introduced
 accessing `username` as `request.user.username`, but it should be accessed
 using `request.user.get_username`. This breaks on custom models which do
 not have a `username` attribute or property.

 (marking with Has patch, because I submitted one on github already).

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

Re: [Django] #26230: RelatedField.related_query_name should default to _meta.default_related_name if defined. (was: default_related_name lookup)

2016-02-17 Thread Django

#26230: RelatedField.related_query_name should default to
_meta.default_related_name if defined.
-+-
 Reporter:  OmegaDroid   |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
-+-

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

Re: [Django] #26230: default_related_name lookup

2016-02-17 Thread Django

#26230: default_related_name lookup
-+-
 Reporter:  OmegaDroid   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * version:  1.9 => master
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 This was also brought up on [https://groups.google.com/d/msg/django-
 users/OGavpqJrw6g/H09wAh35CAAJ django-users] a couple of months ago.

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

[Django] #26230: default_related_name lookup

2016-02-17 Thread Django

#26230: default_related_name lookup
---+
 Reporter:  OmegaDroid |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If I attach a `default_related_name` for my model using the name in a
 model lookup fails.

 For example, if I have the following models:

 {{{
 from django.db import models

 class Foo(models.Model):
 a = models.IntegerField(default=0)


 class Bar(models.Model):
 foo = models.ForeignKey(Foo, related_name='bars')


 class Boo(models.Model):
 foo = models.ForeignKey(Foo)

 class Meta:
 default_related_name = 'boos'
 }}}

 And the following tests:

 {{{
 from django.test import TestCase

 from .models import Foo, Bar, Boo


 class Test(TestCase):
 def setUp(self):
 self.foo = Foo.objects.create()

 def test_related_name_on_field___all_is_fine(self):
 instance = Bar.objects.create(foo=self.foo)

 # get related set
 self.assertEqual(instance, self.foo.bars.first())

 # filter foos through lookup
 self.assertEqual(self.foo, Foo.objects.get(bars=instance))

 def test_related_name_is_default___lookup_fails(self):
 instance = Boo.objects.create(foo=self.foo)

 # get related set
 self.assertEqual(instance, self.foo.boos.first())

 # filter foos through lookup
 self.assertEqual(self.foo, Foo.objects.get(boos=instance))
 }}}

 I get the following error:

 {{{
 django.core.exceptions.FieldError: Cannot resolve keyword 'boos' into
 field. Choices are: a, bars, boo, id
 }}}

 This shows I can use `boos` as a property for `Foo` objects but when i try
 to use it in a lookup it is expecting `boo` rather than `boos`

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

Re: [Django] #25735: Add test tagging to Django test runner

2016-02-17 Thread Django

#25735: Add test tagging to Django test runner
---+
 Reporter:  carljm |Owner:  mrbox
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  1.8
 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
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"d4dc775620fc57e962165eab98a77264e3dd16b2" d4dc775]:
 {{{
 #!CommitTicketReference repository=""
 revision="d4dc775620fc57e962165eab98a77264e3dd16b2"
 Fixed #25735 -- Added support for test tags to DiscoverRunner.

 Thanks Carl Meyer, Claude Paroz, and Simon Charette for 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/064.0275d81464123ddcafe120d15dd285b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26229: Missing check for list_editable in admin

2016-02-17 Thread Django

#26229: Missing check for list_editable in admin
---+--
 Reporter:  alasdairnicol  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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 alasdairnicol):

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


Comment:

 When I get a chance, I will have a closer look at the code and try to work
 out what the problem is .

 At a first glance,
 [https://github.com/django/django/blob/master/tests/modeladmin/tests.py#L1544
 ListDisplayEditableTests] should have a test case similar to
 test_list_display_same_as_list_editable, but with `list_display_links`
 undefined. In that case, there should be a warning if the first item in
 list_display is in list_editable.

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

[Django] #26229: Missing check for list_editable in admin

2016-02-17 Thread Django

#26229: Missing check for list_editable in admin
---+
 Reporter:  alasdairnicol  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Arising from http://stackoverflow.com/questions/35456634/

 If `list_display` and `list_editable` are both lists with a single item,
 and `list_display_links` is not set, then the `list_editable` won't have
 any effect, because the field will be displayed as a link rather than a
 form field. We already have admin checks for usage of list_editable, but
 this case does not appear to be covered.

 {{{
 class CustomAdmin(admin.ModelAdmin):
 list_display = ('status', )
 list_editable = ('status',)
 }}}

 #22792 is a related 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/056.5d01c821abe2a483e5e39ceb452d2765%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26228: 500 Exceptions not logged if firewall blocks outgoing SMTP

2016-02-17 Thread Django

#26228: 500 Exceptions not logged if firewall blocks outgoing SMTP
-+--
 Reporter:  ryanfox  |Owner:
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  logging  | 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:

 Is there a problem if the value of
 [https://docs.djangoproject.com/en/stable/ref/settings/#email-timeout
 settings.EMAIL_TIMEOUT] is less than the value of Gunicorn's timeout?

 I don't understand what change you're proposing.

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

Re: [Django] #26225: Coalesce Multiple Calls to order_by with Same Arguments

2016-02-17 Thread Django

#26225: Coalesce Multiple Calls to order_by with Same Arguments
-+-
 Reporter:  cancan101|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 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 mjtamlyn):

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


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

Re: [Django] #26225: Coalesce Multiple Calls to order_by with Same Arguments

2016-02-17 Thread Django

#26225: Coalesce Multiple Calls to order_by with Same Arguments
-+-
 Reporter:  cancan101|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 jarshwah):

 I agree with Marc. Too complex for very little gain. Imagine the case
 where you have multiple complex ordering expressions:

 {{{
 qs.order_by(Upper('field_a').asc(), Lower('field_b').desc(),
 Concat(F('field_c'), F('field_d')).asc())
 }}}

 If another ordering queryset method is applied, to determine if that was
 "the same" as last time, you could only really do identity checks which
 fails unless the objects are reused, or to generate what the ordering sql
 would be, and comparing that against the existing. Neither of those
 options are fool proof, and generating the sql would be fairly expensive
 for very little gain.

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

Re: [Django] #20932: Issues with model Manager and inheritance.

2016-02-17 Thread Django

Comment (by loic):

I really like the idea of having `Model.objects = models.Manager()` and
let the MRO do its thing. By itself, it wouldn't be that far reaching (I
don't think anyone would have reasons to check for its absence)

The problematic bit would be getting rid of `_default_manager` because
people that added an explicit custom manager named anything but `objects`
would now see their default manager downgraded to the inherited
`models.Manager`.

Unless we apply the same ~~magic~~ logic that currently overrides
`_default_manager` to override an inherited `objects`, but then we can't
say that normal MRO resolution applies.

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

Re: [Django] #26225: Coalesce Multiple Calls to order_by with Same Arguments

2016-02-17 Thread Django

Comment (by mjtamlyn):

Yes, this would make significant unnecessary complexity in my opinion. The
ORM currently abides by a simple rule that chaining on another call
creates a new queryset. We even explicitly use this with `all()` in
`forms.ModelChoiceField` - and that's an API which can ''never'' change
the queryset.

It's worth noting that you could add this kind of behaviour to a custom
queryset class, but you would be inspecting private properties of the
underlying query object to get what you want. Looking at the original
ticket you opened, how I would approach that sort of situation where a you
have code which may have a prefetched query or may not is to use `to_attr`
- prefetch to `_ordered_children` and then have a `ordered_children`
method which returns `_ordered_children` if it exists, or runs the query
if not.

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

Re: [Django] #20932: Issues with model Manager and inheritance.

2016-02-17 Thread Django

* cc: mjtamlyn (added)

Comment:

I think that backwards incompat is acceptable, and pretty natural. The end
result here becomes easy to explain:

- Resolve managers explicitly defined on all models you inherit from
(irrespective of their abstract or concrete nature) using normal MRO
- If there are no managers explicitly defined, create `objects =
models.Manager()` as every model must have a manager.

The guiding point being the implicit creation is a last resort.

Because the existing behaviour is strange and incorrectly documented,
there's no harm in rewriting it to make it logical. It should be easy to
make loud warnings that `MessyBachelorParty.objects` is not defined as
`MessyBachelorParty.events` is.

The other alternative approach, which I have to say I quite like but would
be more far reaching, is to effectively define `objects` on `Model` and
let normal MRO do the rest (subject to model binding). This would mean
every model has a manager called `objects`, which is either the default
manager or a defined custom manager. We scrap `_default_manager` and just
use objects as the default. This would be a much bigger backwards
incompatibility, but in my experience whenever I do define a custom
manager, I either call it `objects`, or call it something else and
redefine `objects`. I find the disappearing nature of `objects` somewhat
strange and magical. Such a change would need to be discussed on the
mailing list, what I'm curious about is whether anyone actually has a
concrete need for `objects` to disappear.

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

Re: [Django] #20932: Issues with model Manager and inheritance.

2016-02-17 Thread Django

#20932: Issues with model Manager and inheritance.
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by loic):

 Just to clarify the nature of the backwards incompatibility:

 {{{
 class BachelorParty(Model):
 events = CustomManager()

 class MessyBachelorParty(BachelorParty):
 pass
 }}}

 `MessyBachelorParty.objects` wouldn't exist anymore, and
 `MessyBachelorParty._default_manager` would be an instance of
 `CustomManager`.

 {{{
 class BachelorParty(Model):
 objects = CustomManager()

 class MessyBachelorParty(BachelorParty):
 pass
 }}}

 `MessyBachelorParty.objects` would become an instance of `CustomManager`
 instead of just `models.Manager`.

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

37 matches

Mail list logo