date:20180905

Re: [Django] #28597: Class-based model indexes containing default primary key doesn't work.

2018-09-05 Thread Django

#28597: Class-based model indexes containing default primary key doesn't work.
-+-
 Reporter:  Дилян Палаузов   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Model.Meta.indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hmm it's weird that the backport wasn't reported back here like the commit
 against master was.

 Here it is for reference cee07ba0880e9d1396795e4823a7371da90cc5cc

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

Re: [Django] #28597: Class-based model indexes containing default primary key doesn't work.

2018-09-05 Thread Django

#28597: Class-based model indexes containing default primary key doesn't work.
-+-
 Reporter:  Дилян Палаузов   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Model.Meta.indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Дилян Палаузов):

 The correction is included in Django 1.11.6, see the release notes.

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

Re: [Django] #29727: Lookup using F() on a non-existing model field doesn't throw an error

2018-09-05 Thread Django

Comment (by Alexander Holmbäck):

Here's my take

In `django.db.models.sql.Query`:

`setup_joins` holds on to `FieldException` raised by `names_to_path` so
that `JoinInfo.transform_function` can reraise if it doesn't find a
satisfying transform.

It seems like `resolve_ref` doesn't need the return value from
`transform_function` (unlike `add_fields`), so it didn't call it, which
accidentally led `FieldError` to never be reraised.

When adding a call to `transform_function` from `resolve_ref`, all tests
passes. Note how I assume `targets` to not be empty, that may be bad.
Also, I haven't confirmed that there are tests for when joins and
transforms are mixed, which could be relevant but also 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/070.7af1c679de02179423fe412497e2ed9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29727: Lookup using F() on a non-existing model field doesn't throw an error

2018-09-05 Thread Django

#29727: Lookup using F() on a non-existing model field doesn't throw an error
-+-
 Reporter:  Vidya Rani D G   |Owner:  Alexander
 |  Holmbäck
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  F() expressions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alexander Holmbäck):

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

Re: [Django] #29712: Add warning in makemessages command if the localecode with `l` flag is not correct

2018-09-05 Thread Django

#29712: Add warning in makemessages command if the localecode with `l` flag is 
not
correct
-+-
 Reporter:  Sanyam Khurana   |Owner:  Vishvajit
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 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
-+-

Comment (by Vishvajit Pathak):

 Now I am thinking more to avoid the coercing and to put just a warning
 message.

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

Re: [Django] #29727: Lookup using F() on a non-existing model field doesn't throw an error

2018-09-05 Thread Django

#29727: Lookup using F() on a non-existing model field doesn't throw an error
-+-
 Reporter:  Vidya Rani D G   |Owner:  Alexander
 |  Holmbäck
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  F() expressions  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alexander Holmbäck):

 * owner:  nobody => Alexander Holmbäck
 * status:  new => assigned
 * has_patch:  0 => 1


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

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

Re: [Django] #29630: Oracle crash querying multiple tables with the same column name when limit/offset is used.

2018-09-05 Thread Django

#29630: Oracle crash querying multiple tables with the same column name when
limit/offset is used.
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:  Accepted
  exception  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: felixx (removed)
 * cc: felixxm (added)


Comment:

 I missed this restriction  Specifying unique aliases sounds better to
 me, I will try to fix it in this week. Thanks for investigating this
 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/068.22c41bdb180d3d89e66d7174cf317aa5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29727: Lookup using F() on a non-existing model field doesn't throw an error

2018-09-05 Thread Django

#29727: Lookup using F() on a non-existing model field doesn't throw an error
-+-
 Reporter:  Vidya Rani D G   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  F() expressions  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alexander Holmbäck):

 Added a test expecting FieldError when F() contains a join that ends with
 something other than a field or transform (test fails in 2.1a1 and above):
 https://github.com/alexh546/django/tree/ticket_29727

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

Re: [Django] #29630: Oracle crash querying multiple tables with the same column name when limit/offset is used.

2018-09-05 Thread Django

#29630: Oracle crash querying multiple tables with the same column name when
limit/offset is used.
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:  Accepted
  exception  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * severity:  Normal => Release blocker


Comment:

 From https://docs.oracle.com/en/database/oracle/oracle-
 database/18/sqlrf/SELECT.html#GUID-CFA006CA-6FF1-4972-821E-6996142A51C6

 > **Restrictions on the row_limiting_clause**
 >
 > This clause is subject to the following restrictions:
 >
 > ** If the select list contains columns with identical names and you
 specify the row_limiting_clause, then an ORA-00918 error occurs**. This
 error occurs whether the identically named columns are in the same table
 or in different tables. You can work around this issue by specifying
 unique column aliases for the identically named columns.

 It looks like we'll have to either alias these columns as the reporter did
 or use the old limiting mechanism on column name collision. This is
 something that should be backported to 2.1 so I'll turn it into a release
 blocker.

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

Re: [Django] #29630: Oracle crash querying multiple tables with the same column name when limit/offset is used. (was: Oracle crash querying multiple tables with the same column name "ORA-00918: column

2018-09-05 Thread Django

#29630: Oracle crash querying multiple tables with the same column name when
limit/offset is used.
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:  Accepted
  exception  |
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.e78f5d355dbea45a21c3b8ff48e9683e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29630: Oracle crash querying multiple tables with the same column name "ORA-00918: column ambiguously defined" (was: Admin interface causes ORA-00918: column ambiguously defined)

2018-09-05 Thread Django

* cc: felixx (added)
* component: contrib.admin => Database layer (models, ORM)
* easy: 1 => 0
* type: Uncategorized => Bug
* stage: Unreviewed => Accepted

Comment:

The ''easy picking'' flag is used for
[https://docs.djangoproject.com/en/2.1/internals/contributing/triaging-
tickets/#easy-pickings tickets that would require small, easy, patches].
For example a typo in an error message or something that be performed why
a search and replace through the code base.

Any ORM bug does't fit into this category. The fact it only manifests
itself on Oracle which a most of contributors have limited knowledge of
also makes it harder to resolve.

I've switched the component to the database layer because while it
manifests itself in the admin in your case such an ambigously defined
query can be trivially constructed by using `select_related('fk')` or
`values('id', 'fk__id')`.

@felixx are you aware of any changes that might caused such breakage? At
this point I suspect some obscure flag Oracle flag might be interfering
with native limit/offset support added in #28670 since the test suite
passes against Oracle 12 on CI.

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

Re: [Django] #29673: Thread urlconf isn't reset after response complete

2018-09-05 Thread Django

#29673: Thread urlconf isn't reset after response complete
-+
 Reporter:  tpict|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  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 Herbert Fortes):

 * cc: Herbert Fortes (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/063.55ecd7086bc88de99e687bb562399225%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29606: Validate the type of ALLOWED_HOSTS

2018-09-05 Thread Django

#29606: Validate the type of ALLOWED_HOSTS
--+
 Reporter:  rafis |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  allowed_hosts | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Herbert Fortes):

 * cc: Herbert Fortes (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/063.a52c5617b67e566a169458620de264b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29712: Add warning in makemessages command if the localecode with `l` flag is not correct

2018-09-05 Thread Django

#29712: Add warning in makemessages command if the localecode with `l` flag is 
not
correct
-+-
 Reporter:  Sanyam Khurana   |Owner:  Vishvajit
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 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
-+-

Comment (by Nick Pope):

 Replying to [comment:13 Claude Paroz]:
 > Improving documentation is welcome, but silently accepting a wrong
 language code also look a bit suspicious. I think I would be happy with a
 warning without coercing anything.

 I agree. I think a warning would make sense, without coercion.

 It is still possible to provide a locale to {{{makemessages}}} where there
 are no actual message catalogs in any of the paths in
 `settings.LOCALE_PATHS`.
 We should probably scrap all the normalization stuff and just output a
 warning message if a locale specified by the user is not in
 {{{all_locales}}}.
 At the moment we output a {{{"processing locale xx_XX"}}} message if
 {{{verbosity > 0}}} which should be fixed to only happen for valid,
 existing locales.

 As an aside, this is checking {{{--locale}}} for {{{makemessages}}}, but
 what about {{{compilemessages}}}? (And are their any others?)

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

Re: [Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by rafaelzinezi):

 Replying to [comment:5 rafaelzinezi]:
 I imagine this should be easy pickings because the 2nd and 3rd columns in
 question are not really necessary, being duplicates of
 django_admin_log.user_id and django_admin_log.content_type_id

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

Re: [Django] #29735: MRO of DeleteView need to be changed.

2018-09-05 Thread Django

* stage: Accepted => Unreviewed

Comment:

Please don't mark you own tickets as ''Accepted'', only someone else who
believes the changes are adequate can do it.

I haven't investigated this in details but I'm a bit worried about
changing the MRO and moving the methods off `DeleteMixin` for the sake of
purity. Don't get me wrong, I think that these changes would make sense if
we were to start from scratch but in this case I feel breakage risks
outweigh the benefits.

See the [https://docs.djangoproject.com/en/2.1/internals/contributing
/triaging-tickets/#accepted ticket triaging documentation] for more
details.

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

Re: [Django] #29735: MRO of DeleteView need to be changed.

2018-09-05 Thread Django

#29735: MRO of DeleteView need to be changed.
-+-
 Reporter:  seokhun kim  |Owner:  seokhun
 Type:   |  kim
  Cleanup/optimization   |   Status:  assigned
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  deletemixin, | Triage Stage:  Accepted
  basedeleteview, deleteview,|
  generic view   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by seokhun kim):

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

Re: [Django] #28597: Class-based model indexes containing default primary key doesn't work.

2018-09-05 Thread Django

#28597: Class-based model indexes containing default primary key doesn't work.
-+-
 Reporter:  Дилян Палаузов   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Model.Meta.indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 This won't be backported to 1.11 per our
 [https://docs.djangoproject.com/en/2.1/internals/release-process/ backport
 policy].

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

Re: [Django] #28477: Strip unused annotations from count queries

2018-09-05 Thread Django

#28477: Strip unused annotations from count queries
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * has_patch:  0 => 1


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

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

Re: [Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by rafaelzinezi):

 * component:  Uncategorized => contrib.admin
 * 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/068.99add3bd76fa167bf48c3a2034ac0e61%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rafaelzinezi):

 * Attachment "id ora bug.jpg" added.

 screenshot of the query highlighting my "theory"

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

Re: [Django] #29630: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29630: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  zelfor5436   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle, admin,   | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by rafaelzinezi):

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


Comment:

 Crossed the same problem. [https://pastebin.com/FaEp3wDa full traceback
 debug @pastebin]

 Was able to extract the offending query from traceback and found that when
 base.html runs it, in this case, it has multiple columns named ID (from 3
 tables: Django_Admin_Log, Auth_User and Django_Content_Type).
 by parsing and running the query in a sql script the same error occurs.
 by aliasing the columns it goes away.


 {{{
 SELECT  DJANGO_ADMIN_LOG.ID logid,
 DJANGO_ADMIN_LOG.ACTION_TIME,
 DJANGO_ADMIN_LOG.USER_ID,
 DJANGO_ADMIN_LOG.CONTENT_TYPE_ID,
 DJANGO_ADMIN_LOG.OBJECT_ID,
 DJANGO_ADMIN_LOG.OBJECT_REPR,
 DJANGO_ADMIN_LOG.ACTION_FLAG,
 DJANGO_ADMIN_LOG.CHANGE_MESSAGE,
 AUTH_USER.ID authid,
 AUTH_USER.PASSWORD,
 AUTH_USER.LAST_LOGIN,
 AUTH_USER.IS_SUPERUSER,
 AUTH_USER.USERNAME,
 AUTH_USER.FIRST_NAME,
 AUTH_USER.LAST_NAME,
 AUTH_USER.EMAIL,
 AUTH_USER.IS_STAFF,
 AUTH_USER.IS_ACTIVE,
 AUTH_USER.DATE_JOINED,
 DJANGO_CONTENT_TYPE.ID contid,
 DJANGO_CONTENT_TYPE.APP_LABEL,
 DJANGO_CONTENT_TYPE.MODEL
 FROM DJANGO_ADMIN_LOG
 INNER JOIN AUTH_USER
 ON (DJANGO_ADMIN_LOG.USER_ID = AUTH_USER.ID)
 LEFT OUTER JOIN DJANGO_CONTENT_TYPE
 ON (DJANGO_ADMIN_LOG.CONTENT_TYPE_ID =
 DJANGO_CONTENT_TYPE.ID)
 ORDER BY DJANGO_ADMIN_LOG.ACTION_TIME DESC
 FETCH FIRST 10 ROWS ONLY
 }}}

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

Re: [Django] #29736: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29736: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  rafaelzinezi |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  oracle admin | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by rafaelzinezi):

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


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

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

Re: [Django] #29735: MRO of DeleteView need to be changed.

2018-09-05 Thread Django

#29735: MRO of DeleteView need to be changed.
-+-
 Reporter:  seokhun kim  |Owner:  seokhun
 Type:   |  kim
  Cleanup/optimization   |   Status:  assigned
Component:  Generic views|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  deletemixin, | Triage Stage:
  basedeleteview, deleteview,|  Unreviewed
  generic view   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by seokhun kim):

 * owner:  nobody => seokhun kim
 * status:  new => assigned
 * version:  2.1 => master
 * needs_docs:  0 => 1


Old description:

> (Please refer to Pull Request: MRO of DeleteView was changed)
>
> I think MRO of DeleteView need to be changed in order to clarify the
> inheritance hierarchy.
> So I refactored BaseDeleteView and DeleteMixin.
>
> * (1) What is better as the super class of BaseDeleteView ?
>   * Currently BaseDeleteView inherits from BaseDetailView.
>   * I think SingleObjectMixin is sufficient.
>   * I think Inheritance of Mixin is better than generic view itself.
>   * So I deleted BaseDetailView in the super class of BaseDeleteView.
> * In order to inherit SingleObjectMixin instead of BaseDetailView,
>   * BaseDeleteView inherits from DeletionMixin.
>   * DeletionMixin inherits from SingleObjectMixin.
> * (2) Where is better on the location of get(), post(), delete() methods
> ?
>   * Currently DeleteMixin provides those methods.
>   * It is bad that Mixin class provides those methods, I think.
>   * So My change is that BaseDeleteView provides get(), post() and
> delete() methods.

New description:

 (Please refer to Pull Request-10362-Updated inheritance chain of the
 generic DeleteView)

 I think MRO of DeleteView need to be changed in order to clarify the
 inheritance hierarchy.
 So I refactored BaseDeleteView and DeleteMixin.

 * (1) What is better as the super class of BaseDeleteView ?
   * Currently BaseDeleteView inherits from BaseDetailView.
   * I think SingleObjectMixin is sufficient.
   * I think Inheritance of Mixin is better than generic view itself.
   * So I deleted BaseDetailView in the super class of BaseDeleteView.
 * In order to inherit SingleObjectMixin instead of BaseDetailView,
   * BaseDeleteView inherits from DeletionMixin.
   * DeletionMixin inherits from SingleObjectMixin.
 * (2) Where is better on the location of get(), post(), delete() methods ?
   * Currently DeleteMixin provides those methods.
   * It is bad that Mixin class provides those methods, I think.
   * So My change is that BaseDeleteView provides get(), post() and
 delete() methods.

--

Comment:

 Documentation exists in the Pull Request-10362-Updated inheritance chain
 of the generic DeleteView.

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2018-09-05 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Doing it for `exists()` as well makes sense.

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

Re: [Django] #29736: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29736: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  rafaelzinezi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle admin | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by rafaelzinezi):

 * Attachment "id ora bug.2.jpg" added.

 screenshot of the query highlighting my "theory"

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

Re: [Django] #29736: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29736: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  rafaelzinezi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle admin | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by rafaelzinezi):

 by parsing and running the query in a script the same error occurs.
 by aliasing the columns it goes away.

 SELECT  DJANGO_ADMIN_LOG.ID logid,
 DJANGO_ADMIN_LOG.ACTION_TIME,
 DJANGO_ADMIN_LOG.USER_ID,
 DJANGO_ADMIN_LOG.CONTENT_TYPE_ID,
 DJANGO_ADMIN_LOG.OBJECT_ID,
 DJANGO_ADMIN_LOG.OBJECT_REPR,
 DJANGO_ADMIN_LOG.ACTION_FLAG,
 DJANGO_ADMIN_LOG.CHANGE_MESSAGE,
 AUTH_USER.ID authid,
 AUTH_USER.PASSWORD,
 AUTH_USER.LAST_LOGIN,
 AUTH_USER.IS_SUPERUSER,
 AUTH_USER.USERNAME,
 AUTH_USER.FIRST_NAME,
 AUTH_USER.LAST_NAME,
 AUTH_USER.EMAIL,
 AUTH_USER.IS_STAFF,
 AUTH_USER.IS_ACTIVE,
 AUTH_USER.DATE_JOINED,
 DJANGO_CONTENT_TYPE.ID contid,
 DJANGO_CONTENT_TYPE.APP_LABEL,
 DJANGO_CONTENT_TYPE.MODEL
 FROM DJANGO_ADMIN_LOG
 INNER JOIN AUTH_USER
 ON (DJANGO_ADMIN_LOG.USER_ID = AUTH_USER.ID)
 LEFT OUTER JOIN DJANGO_CONTENT_TYPE
 ON (DJANGO_ADMIN_LOG.CONTENT_TYPE_ID =
 DJANGO_CONTENT_TYPE.ID)
 ORDER BY DJANGO_ADMIN_LOG.ACTION_TIME DESC
 FETCH FIRST 10 ROWS ONLY

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

Re: [Django] #29736: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29736: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  rafaelzinezi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle admin | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by rafaelzinezi):

 * Attachment "id ora bug.jpg" added.

 screenshot of the query highlighting my "theory"

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

Re: [Django] #29736: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

#29736: Admin interface causes ORA-00918: column ambiguously defined
-+-
 Reporter:  rafaelzinezi |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  oracle admin | Triage Stage:
  exception  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by rafaelzinezi):

 full traceback debug @ https://pastebin.com/FaEp3wDa

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

[Django] #29736: Admin interface causes ORA-00918: column ambiguously defined

2018-09-05 Thread Django

Attempting to log in to the admin interface causes a SQL exception to be
raised when using an Oracle database. The exception throw by Oracle is ...
ORA-00918: column ambiguously defined.
Database: Oracle 12.1
cx_Oracle version: 6.4.1
Python 3.5.2
Steps to reproduce...
1) Start a project
2) Configure the use of Oracle as a database
3) Execute makemigrations
4) Execute migrate
5) Execute createsuperuser
6) Execute runserver
7) Open localhost:8000/admin in a browser
8) Enter admin username/password and click to log in

Was able to extract the offending query from traceback and found that when
base.html runs it, in this case, it has multiple columns named ID (from 3
tables: Django_Admin_Log, Auth_User and Django_Content_Type).

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

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

Re: [Django] #28597: Class-based model indexes containing default primary key doesn't work.

2018-09-05 Thread Django

#28597: Class-based model indexes containing default primary key doesn't work.
-+-
 Reporter:  Дилян Палаузов   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Model.Meta.indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Phil Krylov):

 * cc: Phil Krylov (added)


Comment:

 Can someone backport this to 1.11, please?

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

Re: [Django] #29573: Add link from per-item aggregation topic discussion to `annotate()` ref.

2018-09-05 Thread Django

#29573: Add link from per-item aggregation topic discussion to `annotate()` ref.
-+-
 Reporter:  Thomas Güttler   |Owner:  Vishvajit
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Vishvajit Pathak):

 * needs_better_patch:  1 => 0


Comment:

 Cosmetic changes are added. Thanks Carlton for the review.

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

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

Re: [Django] #29734: Added option to sort message strings for translations by msgid

2018-09-05 Thread Django

#29734: Added option to sort message strings for translations by msgid
-+-
 Reporter:  Eugene Bespaly   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, makemessages   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Vishvajit Pathak):

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

Re: [Django] #29725: Inefficient SQL generated when counting a ManyToMany

2018-09-05 Thread Django

#29725: Inefficient SQL generated when counting a ManyToMany
-+-
 Reporter:  Gavin Wahl   |Owner:  oliver
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Forbes):

 Have we considered making this change for `exists()` as well? I'm sure
 this will generate the join in the same way that `count()` does.

 Also somewhat related: https://code.djangoproject.com/ticket/28477

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

Re: [Django] #28477: Strip unused annotations from count queries

2018-09-05 Thread Django

#28477: Strip unused annotations from count queries
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Forbes):

 WIP PR: https://github.com/django/django/pull/8928/files

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

Re: [Django] #29573: Add link from per-item aggregation topic discussion to `annotate()` ref.

2018-09-05 Thread Django

#29573: Add link from per-item aggregation topic discussion to `annotate()` ref.
-+-
 Reporter:  Thomas Güttler   |Owner:  Vishvajit
 Type:   |  Pathak
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 Small cosmetic adjustments needed on the patch. Vishvajit please uncheck
 'Patch needs improvement' when those are addressed.

 Thanks for the input!

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

Re: [Django] #29733: update_or_create - documentation misleading

2018-09-05 Thread Django

#29733: update_or_create - documentation misleading
-+-
 Reporter:  David Pratten|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 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 Carlton Gibson):

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


Comment:

 Adding the following to the `UpdateOrCreateTests` (in
 [https://github.com/django/django/tree/master/tests/get_or_create
 `get_or_create` module] does not produce a failure:

 {{{
 def test_29733(self):
 p = Person.objects.create(
 first_name='John', last_name='Lennon', birthday=date(1940, 10,
 9)
 )
 p, created = Person.objects.update_or_create(
 pk=p.pk, defaults={
 'first_name':'John',
 }
 )
 self.assertFalse(created)
 }}}

 The `Person` model is unique on the primary key and `first_name` fields.
 (So AFAICS it should be a test case for your example.)

 As such I'm going to close this as invalid. If you can provide a failing
 test case I'm happy to re-open.

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

37 matches

Mail list logo