Re: [Django] #30557: order_by() a parent model crash when Meta.ordering contains expressions.

2019-07-10 Thread Django 
#30557: order_by() a parent model crash when Meta.ordering contains expressions.
-+-
 Reporter:  Jonny Fuller |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Eran Keydar):

 * owner:  Eran Keydar => (none)
 * status:  assigned => new


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

Re: [Django] #30631: Prefixing Q Objects.

2019-07-10 Thread Django 
#30631: Prefixing Q Objects.
-+-
 Reporter:  efficiosoft  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  prefix q objects | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by efficiosoft):

 Ok, I posted to the mailing list, but I think you've misunderstood the use
 case I proposed. Let's see how it goes.

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

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

Re: [Django] #30631: Prefixing Q Objects. (was: Prefixing Q Objects)

2019-07-10 Thread Django 
#30631: Prefixing Q Objects.
-+-
 Reporter:  efficiosoft  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  prefix q objects | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => wontfix


Comment:

 Thanks for this proposition. It is interesting idea but I don't see many
 use cases and to be honest it would be confusing to me to use, e.g.:
 {{{
 Q(Q(field__startswith='x') |
 Q(other_field__startswith='y')).prefix('related_field') &
 Q(base_field__gte=78)
 }}}
 instead of
 {{{
 Q(Q(related_field__field__startswith='x') |
 Q(related_field__other_field__startswith='y')) & Q(base_field__gte=78)
 }}}

 Please write to the DevelopersMailingList if you want other opinions, we
 can re-open this ticket if we reach a consensus on the mailing list.

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

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

Re: [Django] #30631: Prefixing Q Objects

2019-07-10 Thread Django 
#30631: Prefixing Q Objects
-+-
 Reporter:  efficiosoft  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefix q objects | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by efficiosoft):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1


Old description:

> I'm currently spending a lot of time on development of a project using
> Django and worked out something that I think could be of use for all
> Django users.
>
> I added a new `.prefix(prefix)` method to the `Q` object, allowing to
> shift pre-built `q` objects to a related field. I think this can change
> the way people build managers completely, because instead of methods
> returning filtered querysets, one can just return `Q` objects, which can
> then be used from related models without repeating the filtering logic.
>
> This is the simple implementation.
>
> ```
> class Q(django.db.models.Q):
> """
> A custom Q implementation that allows prefixing existing Q objects
> with some
> related field name dynamically.
> """
>
> def prefix(self, prefix):
> """Recursively copies the Q object, prefixing all lookup keys.
>
> The prefix and the existing filter key are delimited by the
> lookup separator __.
> Use this feature to delegate existing query constraints to a
> related field.
> """
> return type(self)(
> *(
> child.prefix(prefix)
> if isinstance(child, Q)
> else (prefix + LOOKUP_SEP + child[0], child[1])
> for child in self.children
> ),
> _connector=self.connector,
> _negated=self.negated,
> )
> ```
>
> What do you think, is it worth creating a PR for this functionality? I
> haven't written the docs yet, but could write something if you like the
> addition.
>
> Best regards
> Robert

New description:

 I'm currently spending a lot of time on development of a project using
 Django and worked out something that I think could be of use for all
 Django users.

 I added a new `.prefix(prefix)` method to the `Q` object, allowing to
 shift pre-built `q` objects to a related field. I think this can change
 the way people build managers completely, because instead of methods
 returning filtered querysets, one can just return `Q` objects, which can
 then be used from related models without repeating the filtering logic.

 This is the simple implementation.

 {{{
 class Q(django.db.models.Q):
 """
 A custom Q implementation that allows prefixing existing Q objects
 with some
 related field name dynamically.
 """

 def prefix(self, prefix):
 """Recursively copies the Q object, prefixing all lookup keys.

 The prefix and the existing filter key are delimited by the lookup
 separator __.
 Use this feature to delegate existing query constraints to a
 related field.
 """
 return type(self)(
 *(
 child.prefix(prefix)
 if isinstance(child, Q)
 else (prefix + LOOKUP_SEP + child[0], child[1])
 for child in self.children
 ),
 _connector=self.connector,
 _negated=self.negated,
 )
 }}}

 What do you think, is it worth creating a PR for this functionality? I
 haven't written the docs yet, but could write something if you like the
 addition.

 Best regards
 Robert

--

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

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

[Django] #30631: Prefixing Q Objects

2019-07-10 Thread Django 
#30631: Prefixing Q Objects
-+-
   Reporter: |  Owner:  nobody
  efficiosoft|
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  prefix q objects
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm currently spending a lot of time on development of a project using
 Django and worked out something that I think could be of use for all
 Django users.

 I added a new `.prefix(prefix)` method to the `Q` object, allowing to
 shift pre-built `q` objects to a related field. I think this can change
 the way people build managers completely, because instead of methods
 returning filtered querysets, one can just return `Q` objects, which can
 then be used from related models without repeating the filtering logic.

 This is the simple implementation.

 ```
 class Q(django.db.models.Q):
 """
 A custom Q implementation that allows prefixing existing Q objects
 with some
 related field name dynamically.
 """

 def prefix(self, prefix):
 """Recursively copies the Q object, prefixing all lookup keys.

 The prefix and the existing filter key are delimited by the lookup
 separator __.
 Use this feature to delegate existing query constraints to a
 related field.
 """
 return type(self)(
 *(
 child.prefix(prefix)
 if isinstance(child, Q)
 else (prefix + LOOKUP_SEP + child[0], child[1])
 for child in self.children
 ),
 _connector=self.connector,
 _negated=self.negated,
 )
 ```

 What do you think, is it worth creating a PR for this functionality? I
 haven't written the docs yet, but could write something if you like the
 addition.

 Best regards
 Robert

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

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

Re: [Django] #30630: MemoryError raised by inspectdb executed on Oracle 12c.

2019-07-10 Thread Django 
#30630: MemoryError raised by inspectdb executed on Oracle 12c.
-+-
 Reporter:  AlexanderRavenheart  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

Comment (by AlexanderRavenheart):

 Tried using the same version of instant client as the database version
 (12.1.0.2.0). Error still appears.

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

Re: [Django] #30630: MemoryError raised by inspectdb executed on Oracle 12c.

2019-07-10 Thread Django 
#30630: MemoryError raised by inspectdb executed on Oracle 12c.
-+-
 Reporter:  AlexanderRavenheart  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

Comment (by Jani Tiainen):

 As instructed use same version of instant client as your database version.
 Sometimes oracle is really picky.

 Also note that sql developer uses JDBC not OCI.  You could try to use
 sqlplus which uses OCI and shoul give some clue if it is OCI thats acting
 funny here.

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

Re: [Django] #30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.

2019-07-10 Thread Django 
#30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.
-+-
 Reporter:  Tilman Koschnick |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tilman Koschnick):

 Thanks a lot for fixing this!

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

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

Re: [Django] #30630: MemoryError raised by inspectdb executed on Oracle 12c.

2019-07-10 Thread Django 
#30630: MemoryError raised by inspectdb executed on Oracle 12c.
-+-
 Reporter:  AlexanderRavenheart  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

Comment (by felixxm):

 Probably it will work also with cursor wrapped by Django:
 {{{
 from django.db import connection:
 with connection.cursor() as cursor:
 cursor.execute()
 }}}
 I think that memory issue is related with more complicated query.
 `init_connection_state()` is used when Django establishes an connection,
 so it should crash not only in `inspectdb`.

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

Re: [Django] #26780: Prefetch objects don't work with slices

2019-07-10 Thread Django 
#26780: Prefetch objects don't work with slices
-+-
 Reporter:  Ludwik Trammer   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch, slicing| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Pavel Lysak):

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

Re: [Django] #30630: MemoryError raised by inspectdb executed on Oracle 12c.

2019-07-10 Thread Django 
#30630: MemoryError raised by inspectdb executed on Oracle 12c.
-+-
 Reporter:  AlexanderRavenheart  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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
-+-

Comment (by AlexanderRavenheart):

 {{{#!python
 import cx_Oracle
 connection = cx_Oracle.connect("user", "password", "TNS")
 cursor = connection.cursor()
 cursor.execute(".")
 }}}
 I executed the query commands as run by inspectdb using directly cx-Oracle
 by following the steps specified above without changing anything else in
 the setup/environment and everything executed without any issues so it is
 not a Visual Studio, Oracle Instant Client or cx-Oracle 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/077.a94f1c13ab488c6f5947ac9d3e03a202%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28289: QuerySet.count() does not with work raw sql annotations on inherited model fields

2019-07-10 Thread Django 
#28289: QuerySet.count() does not with work raw sql annotations on inherited 
model
fields
-+-
 Reporter:  Karolis Ryselis  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   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 Can Sarıgöl):

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

Re: [Django] #30619: runserver fails to close connection if --nothreading specified.

2019-07-10 Thread Django 
#30619: runserver fails to close connection if --nothreading specified.
-+-
 Reporter:  Atsuo Ishimoto   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  2.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  runserver| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"a9c6ab03560424ed7dff24849c8ddaa3e1eae62e" a9c6ab03]:
 {{{
 #!CommitTicketReference repository=""
 revision="a9c6ab03560424ed7dff24849c8ddaa3e1eae62e"
 Fixed #30619 -- Made runserver --nothreading use single threaded
 WSGIServer.

 Browsers often use multiple connections with Connection: keep-alive.
 If --nothreading is specified, the WSGI server cannot accept new
 connections until the old connection is closed, causing hangs.

 Force Connection: close when --nothreading option is used.
 }}}

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

Re: [Django] #30630: MemoryError raised by inspectdb executed on Oracle 12c. (was: MemoryError raised by inspectdb executed on Oracle 12c database)

2019-07-10 Thread Django 
#30630: MemoryError raised by inspectdb executed on Oracle 12c.
-+-
 Reporter:  AlexanderRavenheart  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 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 felixxm):

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


Comment:

 I'm not able to reproduce this issue, but I don't think that's an issue in
 Django. At the beginning I would try to install instance client for the
 same version i.e. "Oracle Instant Client Base Windows x64 version
 12.1.0.2.0" (I know that this should "theoretically" works with 19.3), you
 can also check Visual Studio compatibility.

 To confirm that it is not related with Django you can try to reproduce
 this issue with using `cx_Oracle.cursor`:
 {{{
 import cx_Oracle
 connection = cx_Oracle.connect("user", "password", "TNS")
 cursor = connection.cursor()
 cursor.execute(".")
 }}}

 Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

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

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

[Django] #30630: MemoryError raised by inspectdb executed on Oracle 12c database

2019-07-10 Thread Django 
#30630: MemoryError raised by inspectdb executed on Oracle 12c database
-+-
   Reporter: |  Owner:  nobody
  AlexanderRavenheart|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 These are the queries being executed before the crash:
 {{{#!python
 Query:  ALTER SESSION SET NLS_TERRITORY = 'AMERICA'
 Params:  []
 Query:  ALTER SESSION SET NLS_DATE_FORMAT = '-MM-DD HH24:MI:SS'
 NLS_TIMESTAMP_FORMAT = '-MM-DD HH24:MI:SS.FF' TIME_ZONE = 'UTC'
 Params:  []
 Query:  SELECT 1 FROM DUAL WHERE DUMMY LIKE TRANSLATE(:arg0 USING
 NCHAR_CS) ESCAPE TRANSLATE('\' USING NCHAR_CS)
 Params:  {':arg0': 'X'}
 }}}

 This is the traceback output in the command line:
 {{{#!python
 Traceback (most recent call last):
   File ".\manage.py", line 17, in 
 execute_from_command_line(sys.argv)
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\core\management\__init__.py", line 381, in
 execute_from_command_line
 utility.execute()
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\core\management\__init__.py", line 375, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\core\management\base.py", line 323, in run_from_argv
 self.execute(*args, **cmd_options)
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\core\management\base.py", line 364, in execute
 output = self.handle(*args, **options)
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\core\management\commands\inspectdb.py", line 34, in handle
 for line in self.handle_inspection(options):
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\core\management\commands\inspectdb.py", line 47, in
 handle_inspection
 with connection.cursor() as cursor:
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\db\backends\base\base.py", line 256, in cursor
 return self._cursor()
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\db\backends\base\base.py", line 233, in _cursor
 self.ensure_connection()
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\db\backends\base\base.py", line 217, in ensure_connection
 self.connect()
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\db\backends\base\base.py", line 197, in connect
 self.init_connection_state()
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\db\backends\oracle\base.py", line 259, in
 init_connection_state
 ['X'])
   File "D:\Rudi\Workspace\Visual Studio\PTT Lite\env\lib\site-
 packages\django\db\backends\oracle\base.py", line 510, in execute
 return self.cursor.execute(query, self._param_generator(params))
 MemoryError
 }}}

 The SELECT query returns 1 as a result if executed in Oracle SQL Developer
 so I assume the error is not in the execution of that command.
 I don't know if it's a bug in Django, cx-Oracle or at some other level or
 if it's a configuration issue and have no clue how to proceed.

 Database information:
 - Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit
 Production
 - PL/SQL Release 12.1.0.2.0 - Production
 - "CORE 12.1.0.2.0  Production"
 - TNS for Linux: Version 12.1.0.2.0 - Production
 - NLSRTL Version 12.1.0.2.0 - Production

 Environment:
 - Python 3.7.4 64-bit
 - cx-Oracle 7.2.0
 - Oracle Instant Client Base Windows x64 version 19.3 (zip format)

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

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

Re: [Django] #30557: order_by() a parent model crash when Meta.ordering contains expressions.

2019-07-10 Thread Django 
#30557: order_by() a parent model crash when Meta.ordering contains expressions.
-+-
 Reporter:  Jonny Fuller |Owner:  Eran
 |  Keydar
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #28289: QuerySet.count() does not with work raw sql annotations on inherited model fields

2019-07-10 Thread Django 
#28289: QuerySet.count() does not with work raw sql annotations on inherited 
model
fields
-+-
 Reporter:  Karolis Ryselis  |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   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:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

Re: [Django] #30619: runserver fails to close connection if --nothreading specified.

2019-07-10 Thread Django 
#30619: runserver fails to close connection if --nothreading specified.
-+-
 Reporter:  Atsuo Ishimoto   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  runserver| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #30543: admin.E108 is raised on fields accessible only via instance.

2019-07-10 Thread Django 
#30543: admin.E108 is raised on fields accessible only via instance.
-+-
 Reporter:  ajcsimons|Owner:  ajcsimons
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"ed668796f6c7e59ca3f35e9d87d940e043a3eff3" ed668796]:
 {{{
 #!CommitTicketReference repository=""
 revision="ed668796f6c7e59ca3f35e9d87d940e043a3eff3"
 Fixed #30543 -- Fixed checks of ModelAdmin.list_display for fields
 accessible only via instance.

 Co-Authored-By: Andrew Simons 
 }}}

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

Re: [Django] #30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.

2019-07-10 Thread Django 
#30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.
-+-
 Reporter:  Tilman Koschnick |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1088a9777da86dbf398106761c776edab29b163b" 1088a977]:
 {{{
 #!CommitTicketReference repository=""
 revision="1088a9777da86dbf398106761c776edab29b163b"
 [2.2.x] Fixed #30621 -- Fixed crash of __contains lookup for
 Date/DateTimeRangeField when the right hand side is the same type.

 Thanks Tilman Koschnick for the report and initial patch.
 Thanks Carlton Gibson for the review.

 Regression in 6b048b364ca1e0e56a0d3815bf2be33ac9998355.
 Backport of 799af12056ec9a856f35935d273526338c1f from master
 }}}

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

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

Re: [Django] #30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.

2019-07-10 Thread Django 
#30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.
-+-
 Reporter:  Tilman Koschnick |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"799af12056ec9a856f35935d273526338c1f" 799]:
 {{{
 #!CommitTicketReference repository=""
 revision="799af12056ec9a856f35935d273526338c1f"
 Fixed #30621 -- Fixed crash of __contains lookup for
 Date/DateTimeRangeField when the right hand side is the same type.

 Thanks Tilman Koschnick for the report and initial patch.
 Thanks Carlton Gibson the review.

 Regression in 6b048b364ca1e0e56a0d3815bf2be33ac9998355.
 }}}

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

Re: [Django] #30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.

2019-07-10 Thread Django 
#30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.
-+-
 Reporter:  Tilman Koschnick |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #30628: order_by() on union() querysets results with wrong ordering when the same field type is presented multiple times.

2019-07-10 Thread Django 
#30628: order_by() on union() querysets results with wrong ordering when the 
same
field type is presented multiple times.
-+-
 Reporter:  Julien Enselme   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Julien Enselme):

 Thanks for the quick fix!

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

Re: [Django] #30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.

2019-07-10 Thread Django 
#30621: CheckConstraint crash with __contains lookup on DateTimeRangeFields.
-+-
 Reporter:  Tilman Koschnick |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/11553 PR]

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

Re: [Django] #30517: Add Redis cache backend.

2019-07-10 Thread Django 
#30517: Add Redis cache backend.
-+-
 Reporter:  dulmandakh   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  redis cache  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 It's worth quoting Aymeric's post on the mailing list:

 > To move this forwards, my suggestion would be to write a DEP, to flesh
 out the rationale for a built-in solution, and to focus on the breadth of
 functionality the built-in backend would support. My preference would be a
 basic set of features, like the other cache backends. I believe that's
 what django-redis-cache does. This will leave room for third-party
 packages like django-redis to provide more advanced features. To give a
 concrete example, like other cache and database backends, a redis backend
 could provide persistent connections but not implement a connection pool.
 Until now Django has left the management of connection pools to third-
 party packages.

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

Re: [Django] #30628: order_by() on union() querysets results with wrong ordering when the same field type is presented multiple times.

2019-07-10 Thread Django 
#30628: order_by() on union() querysets results with wrong ordering when the 
same
field type is presented multiple times.
-+-
 Reporter:  Julien Enselme   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"9dee8515d6f2876fa039aaebdfe8e2bc9de63085" 9dee8515]:
 {{{
 #!CommitTicketReference repository=""
 revision="9dee8515d6f2876fa039aaebdfe8e2bc9de63085"
 [2.2.x] Fixed #30628 -- Adjusted expression identity to differentiate
 bound fields.

 Expressions referring to different bound fields should not be
 considered equal.

 Thanks Julien Enselme for the detailed report.

 Regression in bc7e288ca9554ac1a0a19941302dea19df1acd21.

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

Re: [Django] #30628: order_by() on union() querysets results with wrong ordering when the same field type is presented multiple times.

2019-07-10 Thread Django 
#30628: order_by() on union() querysets results with wrong ordering when the 
same
field type is presented multiple times.
-+-
 Reporter:  Julien Enselme   |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"ee6e93ec8727d0f5ed33190a3c354867669ed72f" ee6e93e]:
 {{{
 #!CommitTicketReference repository=""
 revision="ee6e93ec8727d0f5ed33190a3c354867669ed72f"
 Fixed #30628 -- Adjusted expression identity to differentiate bound
 fields.

 Expressions referring to different bound fields should not be
 considered equal.

 Thanks Julien Enselme for the detailed report.

 Regression in bc7e288ca9554ac1a0a19941302dea19df1acd21.
 }}}

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