Re: [Django] #29556: remove_stale_contenttypes --noinput should non-interactively delete stale content types

[Django]

#29556: remove_stale_contenttypes --noinput should non-interactively delete 
stale
content types
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10163 PR for the first option
 above]

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

[Django] #29556: remove_stale_contenttypes --noinput should non-interactively delete stale content types

[Django]

#29556: remove_stale_contenttypes --noinput should non-interactively delete 
stale
content types
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.contenttypes  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I recently noticed that `remove_stale_contenttypes --noinput` does not
 delete stale content types. It simply does nothing and returns,
 effectively making the command a noop. I had been absentmindedly using
 this command for months not realizing it wasn't useful. To use this
 command to delete content types, one must run the command in interactive
 mode and answer "yes" at the prompt. This makes it difficult to use when
 managing a large number of Django sites where it is impractical to run
 interactive commands.

 The previous post_migrate signal, when combined with -`-noinput`, did not
 delete content types due to data loss concerns. However, now that
 `remove_stale_contenttypes` is a standalone management command, I think
 the data ramifications are much more clear and less likely to cause
 unwanted data loss.

 I suggest one the following:

 - (My preferred) Change `remove_stale_contenttypes --noinput` to remove
 stale content types instead of doing nothing. I think this is a more
 intuitive behavior given the arguments. The combination of arguments would
 stop being a noop and provide useful behavior to projects managing a large
 number of Django sites. However, I recognize this has some backwards
 compatibility concerns. The argument would change from doing nothing to
 deleting database records.

 - Add a new argument `--force` that would assume the answer "yes" for all
 prompts. I think this is less optimal as it introduces an argument that
 doesn't need to exist if we could modify the behavior of `--noinput`.

 If the backward compatibility concerns are too much, perhaps it could be
 introduced in stages:

 Next release:

 - Issue a deprecation warning when using `remove_stale_contenttypes
 --noinput`, state that it will delete content types in a future version.

 - Add `--force` arguments so project admins can delete stale content types
 in a non-interactive fashion.

 After a deprecation period:

 - Change `remove_stale_contenttypes --noinput` to delete content types.

 - Deprecate, and eventually remove, `--force`.

 Prior tickets to consider:

 - #24865 -- Add a management command to remove stale content types
 - #25036 -- `manage.py migrate --noinput` does not delete stale content
 types (refers to old post_migrate signal)

 Code of `remove_stale_contenttypes` showing that it is a noop:

 
https://github.com/django/django/blob/338f741c5eb6b91118f6a6b7c34b5e9b47a5661d/django/contrib/contenttypes/management/commands/remove_stale_contenttypes.py#L36-L72

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

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

Re: [Django] #28862: Removing a field from index_together/unique_together and from the model generates a migration that crashes

[Django]

#28862: Removing a field from index_together/unique_together and from the model
generates a migration that crashes
---+
 Reporter:  Artem Maslovskiy   |Owner:  Jeff
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  models migrations  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Jeff):

 * has_patch:  0 => 1


Comment:

 has [https://github.com/django/django/pull/10162 patch] set for
 consideration.

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Sassan Haradji):

 Unfortunately I don't think so. What I needed was exactly left join.
 The query I needed was a rather complicated query, I try to abstract it
 here so that we can investigate it and find out what's needed in Django
 ORM to achieve it.
 Suppose that I have this table:



 {{{
 CREATE TABLE foo(id,related_id,value,type)
 AS VALUES
 ( 1 , 1,  'A1' , 1 ),
 ( 2 , 1,  'A2' , 2 ),
 ( 3 , 1,  'A3' , 3 ),
 ( 4 , 1,  'A4' , 4 ),
 ( 5 , 1,  'A5' , 5 ),
 ( 6 , 2,  'B1' , 1 ),
 ( 7 , 2,  'B2' , 2 ),
 ( 8 , 2,  'B3' , 3 ),
 ( 9 , 2,  'B4' , 4 ),
 ( 10, 2,  'B5' , 5 )
 ;
 }}}

 I want to aggregate these values and make this intermediate table:
 {{{
 -
 |  id   |   related_id   |  values
 |
 -
 |  1|   1|  (('A1',1),('A2',2),('A3',3),('A4',4),('A5',5))
 |
 -
 |  6|   2|  (('B1',1),('B2',2),('B3',3),('B4',4),('B5',5))
 |
 -
 }}}
 To do so I need to do a simple aggregation:
 {{{
 foo.objects.values('related_id').annotate(
 id=Min('id'),
 values=ArrayAgg(
 Func(
 'value',
 'type',
 function='ARRAY',
 template='%(function)s[%(expressions)s]',
 arg_joiner=',',
 ), output_field=ArrayField(ArrayField(models.FloatField())),
 ),
 )
 }}}
 This will generate this sql query (or something equivalent):
 {{{
 SELECT t.*
 FROM (
   SELECT
 min(id),
 related_id,
 array_agg(ARRAY(value, type)) AS values,
   FROM foo
   GROUP BY id
 ) AS t
 }}}
 So far so good. Then I want to order this query based on value column but
 this order should order values of this column that are in a row that has
 type=X. I can do so by this sql:
 {{{
 SELECT t1.*
 FROM (
   SELECT
 min(id),
 related_id,
 array_agg(ARRAY(value, type)) AS values,
   FROM foo
   GROUP BY id
 ) AS t1
 LEFT OUTER JOIN (SELECT value FROM foo WHERE type=X) AS t2 USING (id)
 ORDER BY t2.value
 }}}
 This is where I need this left join. It should be left join cause I don't
 wanna miss rows that don't have X type value.

 Now do you think it's possible to do the above with current Django ORM
 API?
 Consider that this table is really big, and the above sql query is the
 only one I found that executes in rational time and doesn't miss anything.
 Also the real problem is much more complected, the number of columns that
 are involved are much more so if you think there's room for simplifying
 the above sql solution consider that in my real usecase it may not be
 applicable so I please lets concentrate on interpreting the exact above
 query into Django ORM API and not change the sql query so that it fits the
 API.

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

Re: [Django] #26227: Unicode attachment filename displays incorrectly in some clients

[Django]

#26227: Unicode attachment filename displays incorrectly in some clients
-+-
 Reporter:  Sergey Gornostaev|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  email attachment,| Triage Stage:
  filenames, i18n|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Thomi Richards):

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

Re: [Django] #26227: Unicode attachment filename displays incorrectly in some clients

[Django]

#26227: Unicode attachment filename displays incorrectly in some clients
-+-
 Reporter:  Sergey Gornostaev|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  email attachment,| Triage Stage:
  filenames, i18n|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Thomi Richards):

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


Comment:

 Hi,

 I came across this issue in django 1.11.11 - using the `EmailMessage`
 class, attachments with non-ascii characters in their filenames render as
 'noname' in GMail.

 I'm no expert in MIME - I've read RFC2231 and RFC2047, which seem to be
 on-topic for this case. However, the exact "correct" behaviour here isn't
 obvious to me. However, I was able to fix the issue like so:

 {{{
 class EmailMessageWithAttachmentEncoding(EmailMessage):
 def _create_attachment(self, filename, content, mimetype=None):
 attachment = self._create_mime_attachment(content, mimetype)
 if filename:
 try:
 parameters = {
 'filename': filename.encode('ascii'),
 }
 except UnicodeEncodeError:
 # Include both parameters manually because Python's
 implementation
 # only adheres to RFC2231 and not RFC2047 which breaks
 some clients
 # such as GMail.
 filename = Header(filename, 'utf-8').encode()
 parameters = {
 'filename*': filename,  # RFC2231
 'filename': filename,  # RFC2047
 }
 attachment.add_header('Content-Disposition', 'attachment',
 **parameters)
 return attachment
 }}}

 I'm not sure if the django project would accept this as a patch,
 especially since it seems to me like the correct behaviour here is
 somewhat undefined (perhaps there's a MIME expert willing to testify?). In
 any case, this solution has worked for me, and might help others who
 stumble across this page while trying to debug the same issue.

 I've re-opened the issue, since it seems like we probably want django's
 email features to work with GMail, even if the fix differs from what I've
 pasted above.

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

Re: [Django] #29262: Custom Left Outer Join in Queries

[Django]

#29262: Custom Left Outer Join in Queries
-+-
 Reporter:  Sassan Haradji   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM Join | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I'd be curious to know whether or not `FilteredRelation` would solve your
 use case like it did in #29555.

 This expression allows your to specify extra `JOIN` conditions so I'd
 assume annotating the subquery you want to `JOIN` against and then
 referencing it in the `FilteredRelation(condition)` should work. It'd help
 if you could provide your models definition and the exact query you're
 trying to generate through the ORM.

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

Re: [Django] #28540: Document changes to file upload permissions in Django 1.11

[Django]

#28540: Document changes to file upload permissions in Django 1.11
-+-
 Reporter:  Yaroslav Demidenko   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  ImageField, save,| Triage Stage:  Accepted
  permissions|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 As I mentioned in the PR discussion, the new behavior seems consistent
 with the
 
[https://github.com/django/django/commit/ff420b43647dd7f149f000efd2c7eb077f6ba5cf
 original documentation] added with the introduction of the
 `FILE_UPLOAD_PERMISSIONS` setting:
  On most platforms, temporary files will have a mode of `0600`, and files
 saved from memory will be saved using thesystem's standard umask.

 By default, `MemoryFileUploadHandler` is used for files up to
 `settings.FILE_UPLOAD_MAX_MEMORY_SIZE`, otherwise
 `TemporaryFileUploadHandler` is used.

 If we decide not to make a change (probably the discussion should move to
 django-developers), then we could at least add a note to the deployment
 checklist. Carlton proposed adding a system check that warns if the
 `FILE_UPLOAD_PERMISSIONS` setting isn't set but that feels a bit heavy
 handed as none of the open source Django projects I checked have specified
 this setting so presumably it isn't a common 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/064.d48d25a4b8b3f7b89b084ed755cb1a4f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29546: deprecate timezone.FixedOffset in favor of datetime.timezone

[Django]

#29546: deprecate timezone.FixedOffset in favor of datetime.timezone
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"338f741c5eb6b91118f6a6b7c34b5e9b47a5661d" 338f741]:
 {{{
 #!CommitTicketReference repository=""
 revision="338f741c5eb6b91118f6a6b7c34b5e9b47a5661d"
 Fixed #29546 -- Deprecated django.utils.timezone.FixedOffset.
 }}}

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

Re: [Django] #29548: Add official support for MariaDB

[Django]

#29548: Add official support for MariaDB
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * Attachment "window-expression-failures.txt" 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.378120ec59944ac3f566cdabfd3503f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29548: Add official support for MariaDB

[Django]

#29548: Add official support for MariaDB
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I installed MariaDB 10.3 and found the attached test failures for window
 expressions.

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

Re: [Django] #29542: Annotated field created by subquery, referenced inside of F() generates invalid SQL

[Django]

#29542: Annotated field created by subquery, referenced inside of F() generates
invalid SQL
-+-
 Reporter:  Joey Wilhelm |Owner:  felixxm
 Type:  Bug  |   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
-+-
Changes (by felixxm):

 * Attachment "29542.diff" added.

 Test.

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

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

Re: [Django] #29542: Annotated field created by subquery, referenced inside of F() generates invalid SQL

[Django]

#29542: Annotated field created by subquery, referenced inside of F() generates
invalid SQL
-+-
 Reporter:  Joey Wilhelm |Owner:  felixxm
 Type:  Bug  |   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
-+-
Changes (by felixxm):

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


Comment:

 I've prepared
 [https://code.djangoproject.com/attachment/ticket/29542/29542.diff test]
 in our test suite.

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

Re: [Django] #29542: Annotated field created by subquery, referenced inside of F() generates invalid SQL

[Django]

#29542: Annotated field created by subquery, referenced inside of F() generates
invalid SQL
-+-
 Reporter:  Joey Wilhelm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * Attachment "29542.diff" added.

 Test.

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

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

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Schneier):

 I thought about including `message.recipients()`, my hesitation is that it
 will double up the `From` and `CC` pieces since currently we show the MIME
 which already includes that component. I wonder if adding
 `.format_message()` isn't a case of YAGNI or over engineering.

 I do agree that the proposed documentation patch is ugly, it makes
 specific call outs to technical details that don't feel necessary.

 What do you think about also documenting the fact that `filebased`
 inherits from `console`? Having to double up docs is unfortunate.

 Currently `write_message` also includes `'*' * 79`, is that part of the
 overridable interface as well in your solution?

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

Re: [Django] #29549: Document that Field.choices are enforced by model validation

[Django]

#29549: Document that Field.choices are enforced by model validation
-+-
 Reporter:  Evgeny Arshinov  |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"50dc9fad74b4992602584252207f38c5faecc2ba" 50dc9fad]:
 {{{
 #!CommitTicketReference repository=""
 revision="50dc9fad74b4992602584252207f38c5faecc2ba"
 [2.1.x] Fixed #29549 -- Doc'd that Field.choices are enforced by model
 validation.

 Backport of 8b1d361f28c80cb0fa84a3714d711174bd25cdfa from master
 }}}

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

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

Re: [Django] #29549: Document that Field.choices are enforced by model validation

[Django]

#29549: Document that Field.choices are enforced by model validation
-+-
 Reporter:  Evgeny Arshinov  |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.11
 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 GitHub ):

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


Comment:

 In [changeset:"8b1d361f28c80cb0fa84a3714d711174bd25cdfa" 8b1d361f]:
 {{{
 #!CommitTicketReference repository=""
 revision="8b1d361f28c80cb0fa84a3714d711174bd25cdfa"
 Fixed #29549 -- Doc'd that Field.choices are enforced by model validation.
 }}}

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

Re: [Django] #29548: Add official support for MariaDB

[Django]

#29548: Add official support for MariaDB
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"45c035c823bfbd642dc1490f1c555316af403c4c" 45c035c8]:
 {{{
 #!CommitTicketReference repository=""
 revision="45c035c823bfbd642dc1490f1c555316af403c4c"
 Refs #29548 -- Fixed non-GIS test failures on MariaDB.
 }}}

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

Re: [Django] #29527: Multi-column comparisons

[Django]

#29527: Multi-column comparisons
-+-
 Reporter:  Ryan Hiebert |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  QuerySet.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


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

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

Re: [Django] #29549: Document that Field.choices are enforced by model validation (was: Model.save() doesn't validate CHOICES)

[Django]

#29549: Document that Field.choices are enforced by model validation
-+-
 Reporter:  Evgeny Arshinov  |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 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 Tim Graham):

 * status:  new => assigned
 * component:  Database layer (models, ORM) => Documentation
 * owner:  nobody => Tim Graham
 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/10161 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/067.3080d8982589b5e9f8309050ce8658a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29552: Path for 'commands' is incorrect in pt-BR docs

[Django]

#29552: Path for 'commands' is incorrect in pt-BR docs
--+
 Reporter:  Paulo Barros  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:  pt-br | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Paulo Barros):

 Replying to [comment:4 Carlton Gibson]:
 > This is now fixed on Transifex and will make it into the docs next time
 they're deployed. Thanks again for the report, and if you do have capacity
 to help with the translations, that would be amazing too!


 Good to head this.
 How can i contribute ? some Links ?
 Thank you.

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

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

Re: [Django] #29478: cached_property decorator doesn't work with mangled method names

[Django]

#29478: cached_property decorator doesn't work with mangled method names
-+
 Reporter:  Thomas Grainger  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"2a637a45232fa5f046034958a6df91804bbab32c" 2a637a45]:
 {{{
 #!CommitTicketReference repository=""
 revision="2a637a45232fa5f046034958a6df91804bbab32c"
 [2.1.x] Refs #29478 -- Doc'd how to use cached_property with a mangled
 name.

 Backport of 09199734d383691ecf6d163894b447ca45e0ef82 from master
 }}}

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

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

Re: [Django] #29478: cached_property decorator doesn't work with mangled method names

[Django]

#29478: cached_property decorator doesn't work with mangled method names
-+
 Reporter:  Thomas Grainger  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham ):

 In [changeset:"09199734d383691ecf6d163894b447ca45e0ef82" 09199734]:
 {{{
 #!CommitTicketReference repository=""
 revision="09199734d383691ecf6d163894b447ca45e0ef82"
 Refs #29478 -- Doc'd how to use cached_property with a mangled name.
 }}}

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

Re: [Django] #29550: Ease overriding pickling protocol in session serialization and cache backends

[Django]

#29550: Ease overriding pickling protocol in session serialization and cache
backends
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"37835883ad55b3c4c3340eb8721b41fffe3ee0ef" 37835883]:
 {{{
 #!CommitTicketReference repository=""
 revision="37835883ad55b3c4c3340eb8721b41fffe3ee0ef"
 Fixed #29550 -- Eased overriding pickle.dumps() protocol in cache backends
 and session serializer.
 }}}

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

Re: [Django] #27480: Add a Cache.touch(key, timeout=DEFAULT_TIMEOUT) method

[Django]

#27480: Add a Cache.touch(key, timeout=DEFAULT_TIMEOUT) method
-+-
 Reporter:  Victor Porton|Owner:  Nicolas
 |  Noé
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"2d75509bcb1db910da3c568f99b6ac778a79a98f" 2d75509b]:
 {{{
 #!CommitTicketReference repository=""
 revision="2d75509bcb1db910da3c568f99b6ac778a79a98f"
 Refs #27480 -- Moved FileBasedCache content writing logic to a method.
 }}}

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

Re: [Django] #29550: Ease overriding pickling protocol in session serialization and cache backends (was: Usages of pickling should easen protocol overriding)

[Django]

#29550: Ease overriding pickling protocol in session serialization and cache
backends
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Ready for checkin
 * component:  Uncategorized => Core (Other)


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

Re: [Django] #29553: Test client should set Content-Length header to a string rather than integer

[Django]

#29553: Test client should set Content-Length header to a string rather than
integer
-+
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  test content_length  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by GitHub ):

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


Comment:

 In [changeset:"5bea8d256dcf98f6346786f8a4804b84fee5da27" 5bea8d2]:
 {{{
 #!CommitTicketReference repository=""
 revision="5bea8d256dcf98f6346786f8a4804b84fee5da27"
 Fixed #29553 -- Made test client set Content-Length header to a string
 rather than integer.
 }}}

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

Re: [Django] #29555: Left outer join with extra condition

[Django]

#29555: Left outer join with extra condition
-+-
 Reporter:  Enric Calabuig   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Queryset.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 There is also #29262 which talks about custom left outer joins.

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

Re: [Django] #29555: Left outer join with extra condition

[Django]

#29555: Left outer join with extra condition
-+-
 Reporter:  Enric Calabuig   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Queryset.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 Hello Enric,

 Since the introduction of `FilteredRelation`
 [https://docs.djangoproject.com/en/2.0/ref/models/querysets
 /#filteredrelation-objects in Django 2.0] you should be able to achieved
 exactly what you're after with the following


 {{{#!python
 Track.objects.annotate(
 has_tag=FilteredRelation('trackhastag',
 condition=Q(trackhastag__tag=1)),
 ).filter(
 has_tag__isnull=True,
 )
 }}}

 I'll mark this ticket as ''invalid'' for now but feel free to re-open it
 if it doesn't match your use case of `extra()`.

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

Re: [Django] #29555: Left outer join with extra condition

[Django]

#29555: Left outer join with extra condition
-+-
 Reporter:  Enric Calabuig   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Queryset.extra   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


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

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

Re: [Django] #27472: GEOSGeometry('POINT EMPTY').ogr crashes

[Django]

#27472: GEOSGeometry('POINT EMPTY').ogr crashes
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"3411c5551aa4ec141eb214f2928db4b077b41dd3" 3411c555]:
 {{{
 #!CommitTicketReference repository=""
 revision="3411c5551aa4ec141eb214f2928db4b077b41dd3"
 Refs #27472 -- Fixed crash during pickling of empty GEOS point.
 }}}

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

Re: [Django] #20584: Memcached backend's get_many() fail with single-use iterators

[Django]

#20584: Memcached backend's get_many() fail with single-use iterators
-+-
 Reporter:  guyon.moree@…|Owner:  Christian
 |  Barcenas
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"c9c6c166506bec59c57d4e3389e7ccd552e47ffc" c9c6c16]:
 {{{
 #!CommitTicketReference repository=""
 revision="c9c6c166506bec59c57d4e3389e7ccd552e47ffc"
 Fixed #20584 -- Fixed memcached's get_many() with single-use iterators.

 Thanks Guyon Morée for the report.
 }}}

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

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

Re: [Django] #26168: BooleanField is forced to be blank=True

[Django]

#26168: BooleanField is forced to be blank=True
-+-
 Reporter:  fengyehong   |Owner:  Lynn
 Type:   |  Cyrin
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  BooleanField | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


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

Re: [Django] #29553: Test client should set Content-Length header to a string rather than integer (was: Test client handling of CONTENT_LENGTH is different from runserver and wsgi servers)

[Django]

#29553: Test client should set Content-Length header to a string rather than
integer
-+
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  test content_length  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/10159 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/064.dd75d6b489b6dd41738bcf5ae35c4931%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29555: Left outer join with extra condition

[Django]

#29555: Left outer join with extra condition
-+-
   Reporter:  Enric  |  Owner:  nobody
  Calabuig   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  Queryset.extra
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I posted the question below on StackOverflow and the best approach
 possible to solving it as of now seems to be using `.extra()`. My feeling
 is that this is a rather common scenario so it could be that there is a
 better way of getting what I want already.

 Link to the question: [https://stackoverflow.com/questions/51175110/how-
 to-left-outer-join-with-extra-condition-in-django]

 

 I have these three models:
 {{{
 class Track(models.Model):
 title = models.TextField()
 artist = models.TextField()

 class Tag(models.Model):
 name = models.CharField(max_length=50)

 class TrackHasTag(models.Model):
 track = models.ForeignKey('Track', on_delete=models.CASCADE)
 tag = models.ForeignKey('Tag', on_delete=models.PROTECT)
 }}}

 And I want to retrieve all Tracks that are not tagged with a specific tag.
 This gets me what I want:
 `Track.objects.exclude(trackhastag__tag_id='1').only('id')` but it's very
 slow when the tables grow. This is what I get when printing `.query` of
 the queryset:


 {{{
 SELECT "track"."id"
 FROM   "track"
 WHERE  NOT ( "track"."id" IN (SELECT U1."track_id" AS Col1
   FROM   "trackhastag" U1
   WHERE  U1."tag_id" = 1) )
 }}}
 I would like Django to send this query instead:

 {{{
 SELECT "track"."id"
 FROM   "track"
LEFT OUTER JOIN "trackhastag"
 ON "track"."id" = "trackhastag"."track_id"
AND "trackhastag"."tag_id" = 1
 WHERE  "trackhastag"."id" IS NULL;
 }}}

 But haven't found a way to do so. Using a Raw Query is not really an
 option as I have to filter the resulting queryset very often.

 The cleanest workaround I have found is to create a view in the database
 and a model TrackHasTagFoo with managed = False that I use to query like:
 `Track.objects.filter(trackhastagfoo__isnull=True)`. I don't think this is
 an elegant nor sustainable solution as it involves adding Raw SQL to my
 migrations to mantain said view.

 This is just one example of a situation where we need to do this kind of
 left join with an extra condition, but the truth is that we are facing
 this problem in more parts of our application.

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

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

Re: [Django] #29554: Allow loading apps dynamically at runtime (was: Missing feature: load apps dynamically at runtime)

[Django]

#29554: Allow loading apps dynamically at runtime
+--
 Reporter:  Christian González  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  Core (Other)|  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

 * cc: Aymeric Augustin (added)


Comment:

 As the author of the app loading refactor, Aymeric may have some 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/064.d10022355ec48156906ab01a8a7393ca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20584: Memcached backend's get_many() fail with single-use iterators (was: Django's Memcached backend get_many() doesn't handle iterators)

[Django]

#20584: Memcached backend's get_many() fail with single-use iterators
-+-
 Reporter:  guyon.moree@…|Owner:  Christian
 |  Barcenas
 Type:  Bug  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

Re: [Django] #29542: Annotated field created by subquery, referenced inside of F() generates invalid SQL

[Django]

#29542: Annotated field created by subquery, referenced inside of F() generates
invalid SQL
-+-
 Reporter:  Joey Wilhelm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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

[Django] #29554: Missing feature: load apps dynamically at runtime

[Django]

#29554: Missing feature: load apps dynamically at runtime
--+
   Reporter:  Christian González  |  Owner:  nobody
   Type:  New feature | Status:  new
  Component:  Core (Other)|Version:  2.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 I stumbled upon a problem I am not able to solve, and I think this is a
 feature that should be in Django core AFAIKT.
 Until Django 1.x it was possible to add apps dynamically to INSTALLED_APPS
 during runtime, and reload the cache, see here:
 https://stackoverflow.com/questions/19833393/django-dynamically-add-apps-
 as-plugin-building-urls-and-other-settings-automat

 Even if I think this is a bit of a hack and it was never really meant that
 way (?), nevertheless there should be an official possibility to do so.

 I have made a Django application with dynamically apps at server startup
 time - this is no problem, just search for a plugins dir during
 settings.py and add the dotted paths to INSTALLED_APPS. Works fine, but
 one problem remains:

 If I want to enable dynamic app installation - like an "app store" in my
 application - users can download apps from my "store", and enable them
 using my web interface - there currently is no way to achieve that besides
 restarting the Django server, right?

 During setup, Apps.populate() is called - and its docstring says that the
 method is idempotent. Is it possible/allowed/recommended to add some paths
 to django.conf.settings.INSTALLED_APPS and call that populate() again
 later during runtime?

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

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

Re: [Django] #29552: Path for 'commands' is incorrect in pt-BR docs

[Django]

#29552: Path for 'commands' is incorrect in pt-BR docs
--+
 Reporter:  Paulo Barros  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:  pt-br | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Carlton Gibson):

 This is now fixed on Transifex and will make it into the docs next time
 they're deployed. Thanks again for the report, and if you do have capacity
 to help with the translations, that would be amazing too!

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

[Django] #29553: Test client handling of CONTENT_LENGTH is different from runserver and wsgi servers

[Django]

#29553: Test client handling of CONTENT_LENGTH is different from runserver and 
wsgi
servers
-+-
   Reporter:  André  |  Owner:  nobody
  Cruz   |
   Type:  Bug| Status:  new
  Component:  Testing|Version:  master
  framework  |
   Severity:  Normal |   Keywords:  test content_length
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using the Django test client:
 {{{
 (Pdb) type(request.META["CONTENT_LENGTH"])
 
 }}}

 When using runserver or other WSGI application servers:
 {{{
 (Pdb) type(request.META["CONTENT_LENGTH"])
 
 }}}

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

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

Re: [Django] #29552: Path for 'commands' is incorrect in pt-BR docs

[Django]

#29552: Path for 'commands' is incorrect in pt-BR docs
--+
 Reporter:  Paulo Barros  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:  pt-br | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #29552: Path for 'commands' is incorrect in pt-BR docs

[Django]

#29552: Path for 'commands' is incorrect in pt-BR docs
-+-
 Reporter:  Paulo Barros |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  pt-br| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Yes. Good catch.

 Translations are handled on Transifex. [https://www.transifex.com/django
 /django-docs/viewstrings/#pt_BR/howto/42939417?q=text%3A%2Fcommand Here's
 the filter that shows the incorrect translation].

 If you can join the team and add translations and/or review existing
 translations that really helps!

 I'm going to close this here, but I'll keep my eye on it, in case you
 don't get to make the fix.
 (I'm waiting to join the team myself to do this.)

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

Re: [Django] #28598: BCC addresses are ignored in the console and file email backends

[Django]

#28598: BCC addresses are ignored in the console and file email backends
-+-
 Reporter:  zngr |Owner:  Josh
 Type:   |  Schneier
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  mail, bcc| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 I think theres's an ''easy-enough™'' fix available here, rather than just
 documenting that the `BCC` list won't be shown.

 The
 
[https://github.com/django/django/blob/38e904e26576abffed3c257a1a741e1641c6f2de/django/core/mail/backends/console.py#L33-L34
 current console backend does this]:

 {{{
 for message in email_messages:
 self.write_message(message)
 ...
 }}}

 The simple addition is to also write `message.recipients()` at this point.

 If we add and document a `format_message()` hook to
 `console.EmailBackend`, with a stub implementation...


 {{{
 def format_message(self, message):
 return message

 # ... then in send_messages()...
 for message in email_messages:
 self.write_message(self.format_message(message))
 ...
 }}}

 ... then users would be free to subclass the either the console or file
 backends in order to display the BCC 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/062.92ac2514b150c47224a8607328fdd974%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29534: Use rlwrap if available for oracle backend dbshell

[Django]

#29534: Use rlwrap if available for oracle backend dbshell
-+-
 Reporter:  Dan Davis|Owner:  Dan Davis
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * type:  New feature => Cleanup/optimization


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

Re: [Django] #29534: Use rlwrap if available for oracle backend dbshell

[Django]

#29534: Use rlwrap if available for oracle backend dbshell
-+-
 Reporter:  Dan Davis|Owner:  Dan Davis
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * version:  1.11 => master
 * stage:  Unreviewed => Accepted


Comment:

 Hi Dan.

 This seems a reasonable addition. (At least pending the work on the PR!
 :-)

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

Re: [Django] #29214: Invalid SQL when updating after annotating using subquery

[Django]

#29214: Invalid SQL when updating after annotating using subquery
-+-
 Reporter:  Oskar Persson|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
  annotations|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Related: #29542

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

Re: [Django] #29542: Annotated field created by subquery, referenced inside of F() generates invalid SQL

[Django]

#29542: Annotated field created by subquery, referenced inside of F() generates
invalid SQL
-+-
 Reporter:  Joey Wilhelm |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * version:  2.0 => master
 * stage:  Unreviewed => Accepted


Comment:

 OK, this reproduces for me (with a `ready_to_complete.all()` in
 `find_completed_requests`, obviously(?)).

 I can't quite see at this exact moment if this is the same issue as
 #29214 or merely related, so I'll accept and make a note there too.
 (It may be that they end up as duplicates.)

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