Re: [Django] #30687: GIS distance lookups fail within subqueries using OuterRef

[Django]

#30687: GIS distance lookups fail within subqueries using OuterRef
-+-
 Reporter:  Andrew Brown |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Simon Charette):

 * stage:  Accepted => Ready for checkin


Comment:

 I left a few comments for improvement but I'm marking as '''RFC''' because
 they are really minor and could be addressed by the committer.

 Thanks for the patch and tests Andrew, that was a breeze to review.

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

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

Re: [Django] #29545: Nested OuterRef not looking on the right model for the field.

[Django]

#29545: Nested OuterRef not looking on the right model for the field.
-+-
 Reporter:  Aaron Lisman |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  outerref, subquery   | Triage Stage:  Accepted
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 => assigned
 * owner:  nobody => Simon Charette


Comment:

 This is more of a brain dump than a final resolution but I think I might
 have nailed it down. I thought I'd share how I came with what I believe is
 the solution to share a bit of knowledge about how the ORM resolves
 expressions.

 By breaking the query construction in multiple statements and adding
 breakpoints in `OuterRef.resolve_expression` and
 `ResolvedOuterRef.resolve_expression` I noticed that the latter was being
 called '''after''' the complete query construction when it was being
 executed which should not happen. In short all expressions should be
 resolved to their '''final''' expression at this point and in the case of
 `OuterRef` and `ResolvedOuterRef` they should be `Col` instances.

 I then assumed that something must not be have been esolved properly so I
 added a breakpoint before the `print(qs)` and dug into `qs.query`
 internals. By walking the chain of
 `qs.query.annotations['has_item'].query` I noticed that
 `.where.children[0].lhs` was and `Exist` instance and that its
 `.query.where.children[0].rhs` happened to be a `ResolvedOuterRef`
 instance. I then knew that this was the culprit as it should have been a
 `Col` by this point. I also noticed that the copy of the `Exists` present
 as the `.has_tag` expression had its `.query.where.children[0].rhs`
 correctly resolved to a `Col` so I adjusted the test to replace the
 unresolved reference to the `Col` and got the test passing.


 {{{#!python
 def test_nested_outerref(self):
 number = Number.objects.create(num=5)
 Node.objects.create(num=5)
 nested_query = Node.objects.filter(num=OuterRef(OuterRef('num')))
 nested_exist = Exists(nested_query)
 query = Item.objects.annotate(
 has_tag=nested_exist,
 ).filter(has_tag=True)
 exists = Exists(query)
 qs = Number.objects.annotate(
 has_item=exists
 )
 col =
 
qs.query.annotations['has_item'].query.annotations['has_tag'].query.where.children[0].rhs
 
qs.query.annotations['has_item'].query.where.children[0].lhs.query.where.children[0].rhs
 = col
 print(str(qs.query))
 self.assertEqual(qs.get(), number)
 }}}

 From that point I knew that there was an issue resolving
 `qs.query.annotations['has_item'].query.where.children[0].lhs` and then I
 remembered that `sql.Where.resolve_expression` was performing resolving
 for `.rhs` of lookups but not for `.lhs` which brought me to
 [https://github.com/django/django/compare/master...charettes:ticket-29545
 this still incomplete patch] that happens to solve this issue and pass the
 test suite on SQLite so far.

 I've assigned the ticket to myself as I plan to submit the above branch
 for review in the next days. I wouldn't be surprised if it fixed a other
 issues related to subqueries and `OuterRef`.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.d2282a1bbfe2eb29938c13024f44ab87%40djangoproject.com.

Re: [Django] #29545: Nested OuterRef not looking on the right model for the field.

[Django]

#29545: Nested OuterRef not looking on the right model for the field.
-+-
 Reporter:  Aaron Lisman |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  outerref, subquery   | 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):

 Thanks for simplified test case Oskar, that's really valuable.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.0a6e8c2dc6ae5c311bcd71e99a360f2a%40djangoproject.com.

Re: [Django] #29545: Nested OuterRef not looking on the right model for the field.

[Django]

#29545: Nested OuterRef not looking on the right model for the field.
-+-
 Reporter:  Aaron Lisman |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  outerref, subquery   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Oskar Persson):

 * cc: Oskar Persson (added)
 * version:  2.0 => 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.91481e5c945c35fde0f6f6ad3dae52dc%40djangoproject.com.

Re: [Django] #29545: Nested OuterRef not looking on the right model for the field.

[Django]

#29545: Nested OuterRef not looking on the right model for the field.
-+-
 Reporter:  Aaron Lisman |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  outerref, subquery   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Oskar Persson):

 I also ran into this just now and can confirm that the bug exists in both
 2.2.4 and master, tested with the models in tests/queries/models.py:


 {{{
 def test_nested_outerref(self):
 from .models import Item, Node, Number

 Number.objects.create(num=5)
 Node.objects.create(num=5)

 qs = Number.objects.annotate(
 has_item=Exists(
 Item.objects.annotate(
 has_tag=Exists(
 Node.objects.filter(num=OuterRef(OuterRef('num')))
 )
 ).filter(has_tag=True)
 )
 )
 print(qs)
 }}}

 This results in the following exception


 {{{
 django.core.exceptions.FieldError: Cannot resolve keyword 'num' into
 field. Choices are: cover, created,
 creator, creator_id, has_tag, id, modified, name, note, note_id, tags
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.e7f51ab1511811336a16414bf7c2b771%40djangoproject.com.

Re: [Django] #29545: Nested OuterRef not looking on the right model for the field.

[Django]

#29545: Nested OuterRef not looking on the right model for the field.
-+-
 Reporter:  Aaron Lisman |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  outerref, subquery   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * cc: Can Sarıgöl (added)


Comment:

 IMO this query join order should be like this:

 {{{
 inner = Item.objects.filter(

 middle = Invoice.objects.filter(

 outer = Item.objects.filter(
 }}}

 If you want to use nested outerref, middle query has to contain foreign
 keys. Otherwise, this usage needs to include deep related field.


 {{{
 middle = Item.objects.filter(invoices=OuterRef('id'),).annotate(
 expensed=Exists(inner),
 owner=F('invoices__owner')
 ).filter(expensed=False,)
 }}}

 or maybe not necessary nested outerref

 {{{
 inner = Invoice.objects.filter(
 kind=Invoice.EXPENSE,
 owner=OuterRef('invoices__owner'),
 items=OuterRef('id'),
 )
 }}}

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

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

Re: [Django] #30701: Allowing patch_vary_headers() caching utility to handle '*' value.

[Django]

#30701: Allowing patch_vary_headers() caching utility to handle '*' value.
-+-
 Reporter:  Alexander-TX |Owner:  Adnan
 |  Umer
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Adnan Umer):

 * needs_docs:  1 => 0


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

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

Re: [Django] #28428: Add support for Pathlib objects in django.core.storage

[Django]

#28428: Add support for Pathlib objects in django.core.storage
--+
 Reporter:  Tom Forbes|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  File uploads/storage  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Claude Paroz):

 * has_patch:  0 => 1
 * stage:  Someday/Maybe => Accepted


Comment:

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

 It's easier now that Python 3.6 is the minimal version.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.91a39ec803472f35a93a472fa577b28d%40djangoproject.com.

Re: [Django] #30712: Add support for defaults on BLOB and TEXT columns on MySQL 8.0.13+ (was: Add MySQL 8 support for defaults on BLOB and TEXT columns.)

[Django]

#30712: Add support for defaults on BLOB and TEXT columns on MySQL 8.0.13+
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL, default   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

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

Re: [Django] #30712: Add MySQL 8 support for defaults on BLOB and TEXT columns. (was: MySQL 8 supports defaults for BLOB and TEXT columns)

[Django]

#30712: Add MySQL 8 support for defaults on BLOB and TEXT columns.
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  MySQL, default   | 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):

 * keywords:   => MySQL, default
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.37db30f5643fa89cd395e36164abab07%40djangoproject.com.

Re: [Django] #27676: MariaDB 10.2 supports defaults for text columns

[Django]

#27676: MariaDB 10.2 supports defaults for text columns
-+-
 Reporter:  Adam (Chainz)|Owner:  Adam
  Johnson|  (Chainz) Johnson
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * needs_better_patch:  1 => 0


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

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

[Django] #30712: MySQL 8 supports defaults for BLOB and TEXT columns

[Django]

#30712: MySQL 8 supports defaults for BLOB and TEXT columns
-+-
   Reporter:  Adam   |  Owner:  nobody
  (Chainz) Johnson   |
   Type:  New| Status:  new
  feature|
  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  |
-+-
 Whilst implementing #27676 for MariaDB, I learned that MySQL 8.0.13+
 allows defaults for BLOB and TEXT columns as well.

 It has a caveat though - static defaults must always be wrapped in
 parentheses for such columns.

 https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.0af4eefd1932dd4952c1eec87984035c%40djangoproject.com.

Re: [Django] #30711: Document django.contrib.postgres.fields.hstore.KeyTransform. (was: Add HStoreF for F object like querying on HStoreField.)

[Django]

#30711: Document django.contrib.postgres.fields.hstore.KeyTransform.
--+
 Reporter:  Gustav Eiman  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  HStoreField F | 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):

 * component:  contrib.postgres => Documentation
 * owner:  (none) => nobody
 * type:  New feature => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Old description:

> When using F objects for key lookups on HStoreFields it never digs down
> to get the keys but unexpectedly returns the entire object.
>
> Lets say we have this model:
> {{{
> from django.contrib.postgres.fields import HStoreField
> from django.db import models
>
> class Person(models.Model):
> name = models.CharField(max_length=256)
> attributes = HStoreField()
> }}}
>
> We then populate it.
> {{{
> Person.objects.create(name="James", attributes={"age": "30", "height":
> "190"})
> }}}
>
> Here comes the thing that bothers me. If we try to access either of these
> keys the entire attributes cell will be returned.
> {{{
> p = Person.objects.annotate(length=F("attributes__height"))
> p[0].height
> >>> {"age": "30", "height": "190"}
> }}}
>
> While the expected result would be an error or the value of the height
> field, it's not.
>
> I propose either making F objects support these fields or creating a new
> type to handle this, a workaround that I'm playing around with myself.
>
> {{{
> from django.contrib.postgres.fields.jsonb import KeyTransformFactory
>
> class HStoreF(F):
> def resolve_expression(self, query=None, allow_joins=True,
> reuse=None, summarize=False, for_save=False):
> rhs = super().resolve_expression(query, allow_joins, reuse,
> summarize, for_save)
> field_list = self.name.split("__")
> if field_list[-1] == rhs.target.name:
> raise LookupError(
> "HStoreF requires a key lookup in order to avoid unexpected
> behavior. "
> "Please append '__somekey' to '{}'."
> .format("__".join(field_list)))
> return KeyTransformFactory(field_list[-1])(rhs)
>
> }}}
>
> An issue with this is that updating models with it still wont work. As an
> error is raised in {{{Query.resolve_ref()}}} due to the fact that it
> interprets the {{{"__"}}} as an attempted join. This could be solved by
> using a different lookup separator for keys (maybe relevant for JSONField
> to?), but I was unable to successfully implement this.
>
> Similar issue with JSONField: https://code.djangoproject.com/ticket/29769

New description:

 Document `django.contrib.postgres.fields.hstore.KeyTransform` in the
 [https://docs.djangoproject.com/en/dev/ref/contrib/postgres/fields/#hstorefield
 HStoreField documentation] that can be used on the right hand side of a
 filter or an annotation.

--

Comment:

 I changed ticket description, thanks!

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

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

Re: [Django] #30711: Add HStoreF for F object like querying on HStoreField.

[Django]

#30711: Add HStoreF for F object like querying on HStoreField.
--+--
 Reporter:  Gustav Eiman  |Owner:  (none)
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  HStoreField F | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Gustav Eiman):

 Replying to [comment:1 felixxm]:
 > Thanks for the report, I don't think that we should support this by
 adding a custom expression because currently you can always use
 `django.contrib.postgres.fields.hstore.KeyTransform`, e.g.
 > {{{
 > Person.objects.annotate(height=KeyTransform('height', 'attributes'))
 > }}}
 > I don't think that we need to add anything new. IMO, documentating
 `django.contrib.postgres.fields.hstore.KeyTransform` should be enough.
 >
 > It's more complicated for JSONField because nesting multiple
 `KeyTransform()` is not so handy.

 Thank you! I agree, I had no idea this was available.

 Being a first time poster, what do I do now? Should I close this ticket?

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

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

Re: [Django] #30711: Add HStoreF for F object like querying on HStoreField.

[Django]

#30711: Add HStoreF for F object like querying on HStoreField.
--+--
 Reporter:  Gustav Eiman  |Owner:  (none)
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  HStoreField F | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

 * version:  2.2 => master


Comment:

 Thanks for the report, I don't think that we should support this by adding
 a custom expression because currently you can always use
 `django.contrib.postgres.fields.hstore.KeyTransform`, e.g.
 {{{
 Person.objects.annotate(height=KeyTransform('height', 'attributes'))
 }}}
 I don't think that we need to add anything new. IMO, documentating
 `django.contrib.postgres.fields.hstore.KeyTransform` should be enough.

 It's more complicated for JSONField because nesting multiple
 `KeyTransform()` is not so handy.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.44e514fe552991bc351845564eaf08f1%40djangoproject.com.

[Django] #30711: Add HStoreF for F object like querying on HStoreField.

[Django]

#30711: Add HStoreF for F object like querying on HStoreField.
-+-
   Reporter:  tiptop96   |  Owner:  (none)
   Type:  New| Status:  new
  feature|
  Component: |Version:  2.2
  contrib.postgres   |
   Severity:  Normal |   Keywords:  HStoreField F
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using F objects for key lookups on HStoreFields it never digs down to
 get the keys but unexpectedly returns the entire object.

 Lets say we have this model:
 {{{
 from django.contrib.postgres.fields import HStoreField
 from django.db import models

 class Person(models.Model):
 name = models.CharField(max_length=256)
 attributes = HStoreField()
 }}}

 We then populate it.
 {{{
 Person.objects.create(name="James", attributes={"age": "30", "height":
 "190"})
 }}}

 Here comes the thing that bothers me. If we try to access either of these
 keys the entire attributes cell will be returned.
 {{{
 p = Person.objects.annotate(length=F("attributes__height"))
 p[0].height
 >>> {"age": "30", "height": "190"}
 }}}

 While the expected result would be an error or the value of the height
 field, it's not.

 I propose either making F objects support these fields or creating a new
 type to handle this, a workaround that I'm playing around with myself.

 {{{
 from django.contrib.postgres.fields.jsonb import KeyTransformFactory

 class HStoreF(F):
 def resolve_expression(self, query=None, allow_joins=True, reuse=None,
 summarize=False, for_save=False):
 rhs = super().resolve_expression(query, allow_joins, reuse,
 summarize, for_save)
 field_list = self.name.split("__")
 if field_list[-1] == rhs.target.name:
 raise LookupError(
 "HStoreF requires a key lookup in order to avoid unexpected
 behavior. "
 "Please append '__somekey' to '{}'."
 .format("__".join(field_list)))
 return KeyTransformFactory(field_list[-1])(rhs)

 }}}

 An issue with this is that updating models with it still wont work. As an
 error is raised in {{{Query.resolve_ref()}}} due to the fact that it
 interprets the {{{"__"}}} as an attempted join. This could be solved by
 using a different lookup separator for keys (maybe relevant for JSONField
 to?), but I was unable to successfully implement this.

 Similar issue with JSONField: https://code.djangoproject.com/ticket/29769

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.fe579ab93d5dbcefd98faddf3e89c416%40djangoproject.com.

Re: [Django] #30449: Ordering problem in admin.RelatedFieldListFilter and admin.RelatedOnlyFieldListFilter

[Django]

#30449: Ordering problem in admin.RelatedFieldListFilter and
admin.RelatedOnlyFieldListFilter
-+-
 Reporter:  Moritz Pfeiffer  |Owner:  zeynel
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  RelatedFieldListFilter,|
  RelatedOnlyFieldListFilter,|
  ordering   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c2732e6839fffd96b136607f10af95fe58e0de17" c2732e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="c2732e6839fffd96b136607f10af95fe58e0de17"
 [2.2.x] Fixed #30449 -- Fixed
 RelatedFieldListFilter/RelatedOnlyFieldListFilter to respect model's
 Meta.ordering.

 Regression in 6d4e5feb79f7eabe8a0c7c4b87f25b1a7f87ca0b.

 Co-Authored-By: Mariusz Felisiak 

 Backport of 00035672a460b6eb5442d2837bc783f8af28c6f3 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.ba6a3ebbb229ea659d4c783813eabc76%40djangoproject.com.

Re: [Django] #30449: Ordering problem in admin.RelatedFieldListFilter and admin.RelatedOnlyFieldListFilter

[Django]

#30449: Ordering problem in admin.RelatedFieldListFilter and
admin.RelatedOnlyFieldListFilter
-+-
 Reporter:  Moritz Pfeiffer  |Owner:  zeynel
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  RelatedFieldListFilter,|
  RelatedOnlyFieldListFilter,|
  ordering   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"8289fc55fff879df273cb95fdd1b039447f85783" 8289fc55]:
 {{{
 #!CommitTicketReference repository=""
 revision="8289fc55fff879df273cb95fdd1b039447f85783"
 Refs #30449 -- Made RelatedOnlyFieldListFilter respect
 ModelAdmin.ordering.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.6ff6225e08e8623ac6ab55b90cf41826%40djangoproject.com.

Re: [Django] #30449: Ordering problem in admin.RelatedFieldListFilter and admin.RelatedOnlyFieldListFilter

[Django]

#30449: Ordering problem in admin.RelatedFieldListFilter and
admin.RelatedOnlyFieldListFilter
-+-
 Reporter:  Moritz Pfeiffer  |Owner:  zeynel
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  RelatedFieldListFilter,|
  RelatedOnlyFieldListFilter,|
  ordering   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"00035672a460b6eb5442d2837bc783f8af28c6f3" 00035672]:
 {{{
 #!CommitTicketReference repository=""
 revision="00035672a460b6eb5442d2837bc783f8af28c6f3"
 Fixed #30449 -- Fixed RelatedFieldListFilter/RelatedOnlyFieldListFilter to
 respect model's Meta.ordering.

 Regression in 6d4e5feb79f7eabe8a0c7c4b87f25b1a7f87ca0b.

 Co-Authored-By: Mariusz Felisiak 
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.be74aae4822b9002ba29ce49b3179ef4%40djangoproject.com.

Re: [Django] #25139: ModelFormSet: allow swapping unique values

[Django]

#25139: ModelFormSet: allow swapping unique values
--+-
 Reporter:  Jon Dufresne  |Owner:  Parth Patil
 Type:  New feature   |   Status:  assigned
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Someday/Maybe
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Someday/Maybe


Comment:

 [https://groups.google.com/d/topic/django-
 developers/jGk5FvwBy5c/discussion Comment on the mailing list]:

 > What would it take: fetching the set of to_be_unique values and
 comparing it to the set of values submitted and then assigning both within
 a transaction... — meh, possible but I'm not sure it'd be clean, or
 something we'd want to bundle-in, even if we had the solution available,
 vs, putting it in a third-party package...

 I'll bump this to Someday/Maybe for now. Seems like a nice-to-have but
 easier to think about with a proposal in hand.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f0a909cc77e7e2c9c869288845f089b8%40djangoproject.com.

[Django] #30710: impossible without workarounds to see which fields changed when subscribing to signals from generic views

[Django]

#30710: impossible without workarounds to see which fields changed when 
subscribing
to signals from generic views
-+
   Reporter:  MaxR   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  2.1
   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  |
-+
 for example I have simple `generic view`:

 {{{
 #views.py
 class CollectorUpdate(generic.UpdateView):
 model = ReportBase
 fields = ['title', 'db', 'additionalPath', 'start_date', 'end_date',
 'reportTimestamp',
   'updMethod', 'cronStr', 'code', 'code_renew']
 template_name = 'collector/collector_update_form.html'
 }}}

 and subscribe to `post_save` signal:

 {{{
 @receiver(signal=signals.post_save, sender=ReportBase)
 def runCron(sender, **kwargs):
 """Signal handler. Run cron after post_save signal on """
 collector = kwargs.get('instance')
 updated_fields = kwargs.get('update_fields')
 }}}

 but `updated_fields`  always is `None`

 I think the problem is that in generic.UpdateView into `.save()` method it
 is necessary to register a field `field_update` with interesting for me
 fields.
 As workaround i'm using an instyance of saved object:
 {{{
  collector = kwargs.get('instance')
 }}}
 but it's looks strange and it is inconvenient. I have to do a lot of extra
 work

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.b98ecd2740b8ff466f9e2b2d2cb9691f%40djangoproject.com.