Re: [Django] #29413: QuerySet.get_or_create()/update_or_create() shouldn't evaluate lazy defaults unless they are needed

[Django]

#29413: QuerySet.get_or_create()/update_or_create() shouldn't evaluate lazy
defaults unless they are needed
-+-
 Reporter:  Viktor Danyliuk  |Owner:  Liuyang
 Type:   |  Qin
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  QuerySet | Triage Stage:  Accepted
  get_or_create update_or_create |
  lazy   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"6ae7aaa7d6eb880043c4c80009b36e2287bfcb92" 6ae7aaa]:
 {{{
 #!CommitTicketReference repository=""
 revision="6ae7aaa7d6eb880043c4c80009b36e2287bfcb92"
 Fixed #29413 -- Prevented evaluation of
 QuerySet.get_or_create()/update_or_create() defaults unless needed.

 Removed the logic added in 81e05a418dc6f347d9627373288e773c477a9fe0 which
 was obsolete since dba7dc95fc62cbecfd00284bde62ee796f48.
 }}}

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

Re: [Django] #28344: Add for_update parameter to Model.refresh_from_db()

[Django]

#28344: Add for_update parameter to Model.refresh_from_db()
-+-
 Reporter:  Patryk Zawadzki  |Owner:  (none)
 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 adamhooper):

 @Patryk that code block you suggest has a bug.

 {{{
 foo = Foo.objects.get(id=1)  # loads entire record (call these _old_
 values)
 # Now, what happens here if somebody _else_ writes to foo?
 with transaction.atomic():
 Foo.objects.select_for_update.get(pk=foo.pk)  # selects and ignores
 _new_ values
 yield  # Modifies foo ... but foo.save() will save the _old_ values
 }}}

 I think this goes to show how necessary this feature is. Until it comes,
 I'll use this workaround:

 {{{
 foo = Foo.objects.get(id=1)
 with transaction.atomic():
 Foo.objects.select_for_update.get(pk=foo.pk)
 foo.reload_from_db()
 yield
 }}}

 ... which selects the row three times

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

Re: [Django] #29569: Cast() to AutoField generates invalid SQL

[Django]

#29569: Cast() to AutoField generates invalid SQL
-+-
 Reporter:  Andrew Standley  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  cast | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Andrew Standley):

 I'm using `Cast` on generic foreign keys to handle the type coercion in
 the database, so I'm not coding around a 'known' field-type. I would
 indeed just use an `IntegerField`, 'integer' type directly otherwise, and
 as a temporary solution I'm doing just that for the edge case of
 `AutoField`.

 Can you elaborate on how I would use `DatabaseOperations.cast_data_types`
 to fix this? I'm afraid I'm not familiar with that whole side of things.
 It (perhaps naively) seems to me that `DatabaseOperations` is going to
 have no effect on the `Cast` operation compilation as `Cast` selects the
 `db_type` through a different route than the one that
 `DatabaseOperations.cast_data_type` is used in.
 Replying to [comment:1 felixxm]:
 > Thanks for the report. It doesn't sound natural to me to cast to
 `AutoField`, because if you want to get an `integer` / `bigint`, why not
 use it directly? Nevertheless you can use
 `DatabaseOperations.cast_data_types` to fix this easily. This issue
 probably appears on other back-ends.

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

Re: [Django] #29568: Avoid trying to UPDATE a parent model when its child just got INSERT

[Django]

#29568: Avoid trying to UPDATE a parent model when its child just got INSERT
-+-
 Reporter:  François Dupayrat|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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):

 * stage:  Unreviewed => Accepted


Comment:

 With`IndirectChild.objects.create(parent_field=True,
 direct_child_field=True, indirect_child_field=True)`, I see four queries
 at 4d48ddd8f93800a80330ec1dee7b7d4afe6ea95a:
 {{{
 1. INSERT INTO "t29568_parent" ("parent_field") VALUES (true) RETURNING
 "t29568_parent"."id"
 2. UPDATE "t29568_directchild" SET "direct_child_field" = true WHERE
 "t29568_directchild"."parent_ptr_id" = 1
 3. INSERT INTO "t29568_directchild" ("parent_ptr_id",
 "direct_child_field") VALUES (1, true)
 4. INSERT INTO "t29568_indirectchild" ("directchild_ptr_id",
 "indirect_child_field") VALUES (1, true)
 }}}
 Accepting for investigation.

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

Re: [Django] #28917: Remove paginator's unordered queryset warning for a .none() queryset

[Django]

#28917: Remove paginator's unordered queryset warning for a .none() queryset
-+-
 Reporter:  Jeremy Lainé |Owner:  Tim
 Type:   |  Graham 
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  2.0
 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 ):

 * owner:  (none) => Tim Graham 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"4d48ddd8f93800a80330ec1dee7b7d4afe6ea95a" 4d48ddd]:
 {{{
 #!CommitTicketReference repository=""
 revision="4d48ddd8f93800a80330ec1dee7b7d4afe6ea95a"
 Fixed #28917 -- Prevented Paginator's unordered warning on EmptyQuerySet.

 Thanks carltongibson for the idea and weijunji for the initial patch.
 }}}

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

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

Re: [Django] #29569: Cast() to AutoField generates invalid SQL (was: Cast() to the AutoField generates invalid SQL.)

[Django]

#29569: Cast() to AutoField generates invalid SQL
-+-
 Reporter:  Andrew Standley  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  cast | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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

Re: [Django] #29569: Cast() to the AutoField generates invalid SQL. (was: AutoField.cast_db_type returns the wrong 'type' for PostgrestSQL)

[Django]

#29569: Cast() to the AutoField generates invalid SQL.
-+-
 Reporter:  Andrew Standley  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  cast | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: felixxm (added)
 * version:  2.0 => master
 * easy:  0 => 1


Comment:

 Thanks for the report. It doesn't sound natural to me to cast to
 `AutoField`, because if you want to get an `integer` / `bigint`, why not
 use it directly? Nevertheless you can use
 `DatabaseOperations.cast_data_types` to fix this easily. This issue
 probably appears on other back-ends.

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

Re: [Django] #29501: Add support for ./manage.py dbshell -c SQL

[Django]

#29501: Add support for ./manage.py dbshell -c SQL
-+-
 Reporter:  Artem Skoretskiy |Owner:
 |  introquest
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Ready for checkin => Accepted


Comment:

 "Ready for checkin" is set by a patch reviewer. And the patch isn't ready
 for review without tests and documentation.

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

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

Re: [Django] #28296: Add support for aggregation through subqueries

[Django]

#28296: Add support for aggregation through subqueries
-+-
 Reporter:  László Károlyi   |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 Sylvain Zimmer):

 Hello !

 I solved this with a custom class:

 {{{#!python

 class SubQueryCount(Subquery):
 output_field = models.IntegerField()
 def __init__(self, *args, **kwargs):
 Subquery.__init__(self, *args, **kwargs)
 self.queryset =
 self.queryset.annotate(cnt=Count("*")).values("cnt")
 self.queryset.query.set_group_by()  # values() adds a GROUP BY we
 don't want here

 subquery = Media.objects.filter(artist=OuterRef('id'))
 artists_with_count_medias =
 Artist.objects.all().annotate(count_medias=SubQueryCount(subquery))

 }}}

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

[Django] #29569: AutoField.cast_db_type returns the wrong 'type' for PostgrestSQL

[Django]

#29569: AutoField.cast_db_type returns the wrong 'type' for PostgrestSQL
-+-
   Reporter:  Andrew |  Owner:  nobody
  Standley   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  cast
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Using PostgreSQL 10.1 I encountered a problem trying to use `Cast` with an
 `AutoField`. Trying to perform a manual join on generic foreign keys:
 
`Item.objects.filter(pk__in=Activity.objects.filter(content_type=item_ct).annotate(casted_pk=Cast('object_pk',
 AutoField())).values('casted_pk'))`
 The db connection responds with a "psycopg2.ProgrammingError: type
 "serial" does not exist" error.

 Upon investigation, it seems that `AutoField.cast_db_type` uses the
 inherited definition from `Field` and returns `AutoField.db_type`.
 However `AutoField.db_type` returns 'serial', which is a "syntactical
 sugar" (not a true type) in Postgresql and only valid for creation.
 The issue arises when `AutoField.cast_db_type`  also returns 'serial',
 which is invalid.

 More confusingly `AutoField.rel_db_type` has already been overridden and
 correctly returns 'integer'.

 I believe fixing this is as easy as copying the override of
 `AutoField.rel_db_type` to `AutoField.cast_db_type`.
 I'll try to at least get this implemented as a test on my fork, so that it
 is easy to confirm, but in the mean time the models to reproduce are:

 {{{
 class Item(models.Model):
 label = models.CharField(max_length=100)
 cost = models.IntegerField()

 class Activity(models.Model):
 content_type = models.ForeignKey(ContentType,
 on_delete=models.CASCADE)
 object_pk = models.CharField(max_length=100)
 generic_object = GenericForeignKey(fk_field='object_pk')
 }}}

 Reference:
 PostgreSQL docs on 'serial' type
 (https://www.postgresql.org/docs/10/static/datatype-numeric.html#DATATYPE-
 SERIAL)

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

Re: [Django] #29568: Avoid trying to UPDATE a parent model when its child just got INSERT

[Django]

#29568: Avoid trying to UPDATE a parent model when its child just got INSERT
-+-
 Reporter:  François Dupayrat|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 I guess a first experiment would be to make the change and run the test
 suite to see the outcome.

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

Re: [Django] #29567: It raise FieldError when the F() function uses a forign key field.

[Django]

#29567: It raise FieldError when the F() function uses a forign key field.
---+--
 Reporter:  HongWeipeng|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  2.0
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Dan Collins):

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


Comment:

 Duplicate of (wontfix) #14104, see also
 https://docs.djangoproject.com/en/dev/topics/db/queries/#updating-
 multiple-objects-at-once

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

Re: [Django] #29568: Avoid trying to UPDATE a parent model when its child just got INSERT

[Django]

#29568: Avoid trying to UPDATE a parent model when its child just got INSERT
-+-
 Reporter:  François Dupayrat|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by François Dupayrat:

Old description:

> Hello,
>
> While sorting through queries, I noticed something unusual: let's say you
> have non-abstract models inheritance:
> {{{
> class Parent(models.Model):
>   parent_field = models.BooleanField()
>
> class DirectChild(Parent):
>   direct_child_field = models.BooleanField()
>
> class IndirectChild(DirectChild):
>   indirect_child_field = models.BooleanField()
> }}}
>
> When trying to create IndirectChild, I would expect 3 queries to be done:
> * INSERT Parent
> * INSERT DirectChild
> * INSERT IndirectChild
>
> Instead, since they all share the same PK, 5 queries are done:
> * INSERT Parent
> * UPDATE DirectChild (since it has a PK)
> * INSERT DirectChild (because previous UPDATE failed)
> * UPDATE IndirectChild (since it has a PK)
> * INSERT IndirectChild (because previous UPDATE failed)
>
> I found a fix that worked for me by modifying _save_parents and save_base
> in django/db/models/base.py: _save_parents return if something was
> inserted (default to fAlse if there is no parent), and force_insert if
> the parent was inserted in both methods (because if there parent was
> inserted, the child can't possibly exist).
>
> Being a beginner, I'm really wary of breaking something. Could someone if
> it's something wanted by Django and check if there is obvious mistake?
> Here is the modified method (without irrelevant code, materialized as
> [...]):
> {{{
> def _save_parents([...]):
> [...]
> inserted = False
> for parent, field in meta.parents.items():
> [...]
> parent_inserted = self._save_parents(cls=parent, using=using,
> update_fields=update_fields)
> updated = self._save_table(cls=parent, using=using,
> update_fields=update_fields, force_insert=parent_inserted)
> if not updated:
> inserted = True
> [...]
> return inserted
> def save_base([...]):
> [...]
> with transaction.atomic(using=using, savepoint=False):
> parent_inserted = False
> if not raw:
> parent_inserted = self._save_parents(cls, using,
> update_fields)
> updated = self._save_table(raw, cls, force_insert or
> parent_inserted, force_update, using, update_fields)
> [...]
> }}}

New description:

 Hello,

 While sorting through queries, I noticed something unusual: let's say you
 have non-abstract models inheritance:
 {{{
 class Parent(models.Model):
   parent_field = models.BooleanField()

 class DirectChild(Parent):
   direct_child_field = models.BooleanField()

 class IndirectChild(DirectChild):
   indirect_child_field = models.BooleanField()
 }}}

 When trying to create IndirectChild, I would expect 3 queries to be done:
 * INSERT Parent
 * INSERT DirectChild
 * INSERT IndirectChild

 Instead, since they all share the same PK, 5 queries are done:
 * INSERT Parent
 * UPDATE DirectChild (since it has a PK)
 * INSERT DirectChild (because previous UPDATE failed)
 * UPDATE IndirectChild (since it has a PK)
 * INSERT IndirectChild (because previous UPDATE failed)

 I found a fix that worked for me by modifying _save_parents and save_base
 in django/db/models/base.py: _save_parents return if something was
 inserted (default to fAlse if there is no parent), and force_insert if the
 parent was inserted in both methods (because if there parent was inserted,
 the child can't possibly exist).

 Being a beginner, I'm really wary of breaking something. Could someone if
 it's something wanted by Django and check if there is obvious mistake?
 Here is the modified method (without irrelevant code, materialized as
 [...]):
 {{{
 def _save_parents([...]):
 [...]
 inserted = False
 for parent, field in meta.parents.items():
 [...]
 parent_inserted = self._save_parents(cls=parent, using=using,
 update_fields=update_fields)
 updated = self._save_table(cls=parent, using=using,
 update_fields=update_fields, force_insert=parent_inserted)
 if not 

Re: [Django] #29568: Avoid trying to UPDATE a parent model when its child just got INSERT

[Django]

#29568: Avoid trying to UPDATE a parent model when its child just got INSERT
-+-
 Reporter:  François Dupayrat|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by François Dupayrat:

Old description:

> Hello,
>
> While sorting through queries, I noticed something unusual: let's say you
> have non-abstract models inheritance:
> {{{
> class Parent(models.Model):
>   parent_field = models.BooleanField()
>
> class DirectChild(Parent):
>   direct_child_field = models.BooleanField()
>
> class IndirectChild(DirectChild):
>   indirect_child_field = models.BooleanField()
> }}}
>
> When trying to create IndirectChild, I would expect 3 queries to be done:
> * INSERT Parent
> * INSERT DirectChild
> * INSERT IndirectChild
>
> Instead, since they all share the same PK, 5 queries are done:
> * INSERT Parent
> * UPDATE DirectChild (since it has a PK)
> * INSERT DirectChild (because previous UPDATE failed)
> * UPDATE IndirectChild (since it has a PK)
> * INSERT IndirectChild (because previous UPDATE failed)
>
> I found a fix that worked for me by modifying _save_parents in
> django/db/models/base.py to return if something was inserted (default to
> fAlse if there is no parent), and force_insert if the parent was inserted
> (because if there parent was inserted, the child can't possibly exist).
>
> Being a beginner, I'm really wary of breaking something. Could someone if
> it's something wanted by Django and check if there is obvious mistake?
> Here is the modified method:
> {{{
> def _save_parents(self, cls, using, update_fields):
> """Save all the parents of cls using values from self."""
> meta = cls._meta
> inserted = False
> for parent, field in meta.parents.items():
> # Make sure the link fields are synced between parent and
> self.
> if (field and getattr(self, parent._meta.pk.attname) is None
> and
> getattr(self, field.attname) is not None):
> setattr(self, parent._meta.pk.attname, getattr(self,
> field.attname))
> parent_inserted = self._save_parents(cls=parent, using=using,
> update_fields=update_fields)
> updated = self._save_table(cls=parent, using=using,
> update_fields=update_fields, force_insert=parent_inserted)
> if not updated:
> inserted = True
> # Set the parent's PK value to self.
> if field:
> setattr(self, field.attname,
> self._get_pk_val(parent._meta))
> # Since we didn't have an instance of the parent handy
> set
> # attname directly, bypassing the descriptor. Invalidate
> # the related object cache, in case it's been
> accidentally
> # populated. A fresh instance will be re-built from the
> # database if necessary.
> if field.is_cached(self):
> field.delete_cached_value(self)
> return inserted
> }}}

New description:

 Hello,

 While sorting through queries, I noticed something unusual: let's say you
 have non-abstract models inheritance:
 {{{
 class Parent(models.Model):
   parent_field = models.BooleanField()

 class DirectChild(Parent):
   direct_child_field = models.BooleanField()

 class IndirectChild(DirectChild):
   indirect_child_field = models.BooleanField()
 }}}

 When trying to create IndirectChild, I would expect 3 queries to be done:
 * INSERT Parent
 * INSERT DirectChild
 * INSERT IndirectChild

 Instead, since they all share the same PK, 5 queries are done:
 * INSERT Parent
 * UPDATE DirectChild (since it has a PK)
 * INSERT DirectChild (because previous UPDATE failed)
 * UPDATE IndirectChild (since it has a PK)
 * INSERT IndirectChild (because previous UPDATE failed)

 I found a fix that worked for me by modifying _save_parents and save_base
 in django/db/models/base.py: _save_parents return if something was
 inserted (default to fAlse if there is no parent), and force_insert if the
 parent was inserted in both methods (because if there parent was inserted,
 the child can't possibly exist).

 Being a beginner, I'm really wary of breaking something. Could someone if
 it's something wanted by Django and check if there is 

[Django] #29568: Avoid trying to UPDATE a parent model when its child just got INSERT

[Django]

#29568: Avoid trying to UPDATE a parent model when its child just got INSERT
-+-
   Reporter:  François   |  Owner:  nobody
  Dupayrat   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  master
  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  |
-+-
 Hello,

 While sorting through queries, I noticed something unusual: let's say you
 have non-abstract models inheritance:
 {{{
 class Parent(models.Model):
   parent_field = models.BooleanField()

 class DirectChild(Parent):
   direct_child_field = models.BooleanField()

 class IndirectChild(DirectChild):
   indirect_child_field = models.BooleanField()
 }}}

 When trying to create IndirectChild, I would expect 3 queries to be done:
 * INSERT Parent
 * INSERT DirectChild
 * INSERT IndirectChild

 Instead, since they all share the same PK, 5 queries are done:
 * INSERT Parent
 * UPDATE DirectChild (since it has a PK)
 * INSERT DirectChild (because previous UPDATE failed)
 * UPDATE IndirectChild (since it has a PK)
 * INSERT IndirectChild (because previous UPDATE failed)

 I found a fix that worked for me by modifying _save_parents in
 django/db/models/base.py to return if something was inserted (default to
 fAlse if there is no parent), and force_insert if the parent was inserted
 (because if there parent was inserted, the child can't possibly exist).

 Being a beginner, I'm really wary of breaking something. Could someone if
 it's something wanted by Django and check if there is obvious mistake?
 Here is the modified method:
 {{{
 def _save_parents(self, cls, using, update_fields):
 """Save all the parents of cls using values from self."""
 meta = cls._meta
 inserted = False
 for parent, field in meta.parents.items():
 # Make sure the link fields are synced between parent and
 self.
 if (field and getattr(self, parent._meta.pk.attname) is None
 and
 getattr(self, field.attname) is not None):
 setattr(self, parent._meta.pk.attname, getattr(self,
 field.attname))
 parent_inserted = self._save_parents(cls=parent, using=using,
 update_fields=update_fields)
 updated = self._save_table(cls=parent, using=using,
 update_fields=update_fields, force_insert=parent_inserted)
 if not updated:
 inserted = True
 # Set the parent's PK value to self.
 if field:
 setattr(self, field.attname,
 self._get_pk_val(parent._meta))
 # Since we didn't have an instance of the parent handy set
 # attname directly, bypassing the descriptor. Invalidate
 # the related object cache, in case it's been accidentally
 # populated. A fresh instance will be re-built from the
 # database if necessary.
 if field.is_cached(self):
 field.delete_cached_value(self)
 return inserted
 }}}

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

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniel Miller):

 Ole Laursen: that's a good idea. I'm a bit busy with other work right now,
 but I'll add it to my backlog.

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

Re: [Django] #29567: It raise FieldError when the F() function uses a forign key field.

[Django]

#29567: It raise FieldError when the F() function uses a forign key field.
---+--
 Reporter:  HongWeipeng|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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
---+--
Description changed by HongWeipeng:

Old description:

> ```
> class B(models.Model):
> name = models.CharField(max_length=10)
>
> class A(models.Model):
> name = models.CharField(max_length=10)
> b = models.ForeignKey('B', on_delete=models.CASCADE)
> ```
> And then:
> ```
> A.objects.all().update(name=F('b__name'))
>
> raise FieldError("Joined field references are not permitted in this
> query")
> django.core.exceptions.FieldError: Joined field references are not
> permitted in this query
> ```

New description:

 {{{#!python
 class B(models.Model):
 name = models.CharField(max_length=10)

 class A(models.Model):
 name = models.CharField(max_length=10)
 b = models.ForeignKey('B', on_delete=models.CASCADE)
 }}}
 And then:
 {{{#!python
 A.objects.all().update(name=F('b__name'))

 raise FieldError("Joined field references are not permitted in this
 query")
 django.core.exceptions.FieldError: Joined field references are not
 permitted in this query
 }}}

--

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

[Django] #29567: It raise FieldError when the F() function uses a forign key field.

[Django]

#29567: It raise FieldError when the F() function uses a forign key field.
-+
   Reporter:  HongWeipeng|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |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  |
-+
 ```
 class B(models.Model):
 name = models.CharField(max_length=10)

 class A(models.Model):
 name = models.CharField(max_length=10)
 b = models.ForeignKey('B', on_delete=models.CASCADE)
 ```
 And then:
 ```
 A.objects.all().update(name=F('b__name'))

 raise FieldError("Joined field references are not permitted in this
 query")
 django.core.exceptions.FieldError: Joined field references are not
 permitted in this query
 ```

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

Re: [Django] #29425: Auto language redirect does not work if prefix_default_language=False in root URLConf

[Django]

#29425: Auto language redirect does not work if prefix_default_language=False in
root URLConf
-+-
 Reporter:  Nathan Humphreys |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 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 Carlton Gibson):

 * cc: Carlton Gibson (added)


Comment:

 So why is the behaviour as it is?

 [https://github.com/django/django/pull/6264#issuecomment-194897558
 Explanation from PR 6264], which added the extra test and behaviour:



 > The redirect should only happen on `/` URL, with
 `prefix_default_language` set to `True` (default behaviour).
 >
 > Each other request (like `/fr/whatever/`) should not look at `Accept-
 Language` header at all,
 > just serve the page for the language requested in URL.
 >
 > When the `prefix_default_language` is `False` the `/` url is the same as
 `/en/`
 > (with `settings.LANGUAGE_CODE=en`) so we should just ignore the `Accept-
 Language` 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/069.d14e93c527f68d702d4401a69c561e78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28917: Remove paginator's unordered queryset warning for a .none() queryset

[Django]

#28917: Remove paginator's unordered queryset warning for a .none() queryset
-+-
 Reporter:  Jeremy Lainé |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  2.0
 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 Carlton Gibson):

 * owner:  Junji Wei => (none)
 * needs_better_patch:  1 => 0
 * status:  assigned => new
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/10184 New PR] from Josh Schneier.

 Minor change to docstring suggested but otherwise, looks good.

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

Re: [Django] #29501: Add support for ./manage.py dbshell -c SQL

[Django]

#29501: Add support for ./manage.py dbshell -c SQL
-+-
 Reporter:  Artem Skoretskiy |Owner:
 |  introquest
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by introquest):

 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

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

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