Re: [Django] #32971: System check methods can yield their items instead of creating lists at every layer

[Django]

#32971: System check methods can yield their items instead of creating lists at
every layer
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  dev
  checks)|
 Severity:  Normal   |   Resolution:  wontfix
 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 Mariusz Felisiak):

 Replying to [comment:5 Chris Jerdonek]:
 > You can see the public method calling several internal methods --
 unpacking each of their results to create the new list. Each internal
 layer adds unnecessary list creations.

 True, but I don't think that's a big issue. I'd like to keep internal
 methods consistent with what we have in docs (we recommend creating
 internal `_check...` methods which use this pattern).

-- 
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.07d2907371a023ae768f48ac01674502%40djangoproject.com.

Re: [Django] #32971: System check methods can yield their items instead of creating lists at every layer

[Django]

#32971: System check methods can yield their items instead of creating lists at
every layer
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  dev
  checks)|
 Severity:  Normal   |   Resolution:  wontfix
 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 Chris Jerdonek):

 > Thanks for this proposition, however it's ​documented that check
 function must return a list of messages. Also, folks can extend checks at
 any level, see ​examples. I don't think it's worth backward compatibility
 concerns.

 I was talking also about the internal check methods (e.g. the ones whose
 names start with an underscore), which are called by the public methods.
 Here is an example:
 
https://github.com/django/django/blob/f331eba6d576752dd79c4b37c41d981daa537fe6/django/db/models/fields/__init__.py#L198-L204
 You can see the public method calling several internal methods --
 unpacking each of their results to create the new list. Each internal
 layer adds unnecessary list creations.

-- 
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.107e76f6c653efb8c3d543f3a55b6f85%40djangoproject.com.

Re: [Django] #32971: System check methods can yield their items instead of creating lists at every layer

[Django]

#32971: System check methods can yield their items instead of creating lists at
every layer
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (System |  Version:  dev
  checks)|
 Severity:  Normal   |   Resolution:  wontfix
 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 Mariusz Felisiak):

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


Comment:

 Thanks for this proposition, however it's
 [https://docs.djangoproject.com/en/3.2/topics/checks/ documented] that
 check function must return a **list** of messages. Also, folks can extend
 checks at any level, see
 [https://docs.djangoproject.com/en/3.2/topics/checks/#field-model-manager-
 and-database-checks examples]. I don't think it's worth backward
 compatibility concerns.

-- 
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.2bc82e77696cf196ea592aafa06b0f08%40djangoproject.com.

Re: [Django] #32972: Django ORM raw query not playing nice with Geometric Point objects

[Django]

#32972: Django ORM raw query not playing nice with Geometric Point objects
-+-
 Reporter:  Donovan  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ORM raw query| Triage Stage:
  geometric location point   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Using `.raw()` is a last resort. Django takes a raw SQL query, executes
 it, and returns results (as documented), it will not automatically add any
 data conversion to columns. Geometry columns returned by the ORM are
 wrapped with db-specific functions, e.g. `%s::bytea` on PostgreSQL or
 `SDO_UTIL.TO_WKBGEOMETRY(%s)` on Oracle.

 If you're having trouble understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

-- 
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/072.5ac68a6902cffa5094dfe0ab433dc0d3%40djangoproject.com.

Re: [Django] #32973: Pass generator expression to str.join() instead of list / tuple throughout code base

[Django]

#32973: Pass generator expression to str.join() instead of list / tuple 
throughout
code base
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 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 Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => Core (Other)


Comment:

 A list comprehension is preferable here as `str.join()` converts to list
 internally anyway. It is better performance to provide a list up front.
  - https://stackoverflow.com/questions/9060653/list-comprehension-without-
 in-python/9061024#9061024
  - https://github.com/adamchainz/flake8-comprehensions/issues/156

-- 
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.9496ccd67b47f2727f88c0eaf42d8d43%40djangoproject.com.

Re: [Django] #25264: Misleading list of options available for manage.py commands

[Django]

#25264: Misleading list of options available for manage.py commands
-+-
 Reporter:  Maxime Lorant|Owner:  Jan Szoja
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Jan Szoja):

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


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

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

[Django] #32973: Pass generator expression to str.join() instead of list / tuple throughout code base

[Django]

#32973: Pass generator expression to str.join() instead of list / tuple 
throughout
code base
+
   Reporter:  Chris Jerdonek|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |Version:  dev
   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 |
+
 In many places throughout Django's code base, a list or tuple is passed to
 `str.join()` when a generator expression would suffice. For example,
 instead of `', '.join([self.quote_name(field.column) for field in
 fields])` one can do `', '.join(self.quote_name(field.column) for field in
 fields)`. This eliminates an unneeded list creation. Many (but not all)
 examples can be found by searching the code base for `.join([`.

-- 
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/052.5354ea59e1d77059ef19041bdfc05743%40djangoproject.com.

Re: [Django] #32971: System check methods can yield their items instead of creating lists at every layer (was: Internal Field.check() methods don't need to construct and return lists)

[Django]

#32971: System check methods can yield their items instead of creating lists at
every layer
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (System |  Version:  dev
  checks)|
 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 Chris Jerdonek):

 * component:  Database layer (models, ORM) => Core (System checks)


-- 
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.fd19cc4c59cc4db109ec184a24e00ed9%40djangoproject.com.

Re: [Django] #32971: Internal Field.check() methods don't need to construct and return lists

[Django]

#32971: Internal Field.check() methods don't need to construct and return lists
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (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 Chris Jerdonek):

 Actually, it looks like this observation may apply to the entire system
 check framework. Currently, it looks like lists are constructed at every
 layer in nested fashion, when it appears that it would work equally well
 for items to be yielded up the stack.

-- 
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.c81d006d3091856ebc9684937fbd305d%40djangoproject.com.

Re: [Django] #32966: Time-related _check_fix_default_value() methods can be optimized / simplified and have a bug (was: time-related _check_fix_default_value() methods can be optimized / simplified)

[Django]

#32966: Time-related _check_fix_default_value() methods can be optimized /
simplified and have a bug
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 |  Jerdonek
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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
-+-

-- 
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.aa556ed790f10571620101d532ff3aed%40djangoproject.com.

Re: [Django] #32972: Django ORM raw query not playing nice with Geometric Point objects

[Django]

#32972: Django ORM raw query not playing nice with Geometric Point objects
-+-
 Reporter:  Donovan  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  ORM raw query| Triage Stage:
  geometric location point   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Donovan):

 * Attachment "expected location after serializing.png" added.

 What the the Point object should have for latitude and longitude

-- 
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/072.3dcdd7a7474ff21ac0cd982ad19d4e8b%40djangoproject.com.

Re: [Django] #32971: Internal Field.check() methods don't need to construct and return lists

[Django]

#32971: Internal Field.check() methods don't need to construct and return lists
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (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 Chris Jerdonek:

Old description:

> I noticed that many of the internal "check()" methods used by `Field`
> subclasses return lists (including the empty list) when they can just
> yield items (or yield nothing). This is because the concrete `check()`
> implementations unpack the return value when constructing a new list. See
> here for one example of such a `check()` method:
> https://github.com/django/django/blob/f331eba6d576752dd79c4b37c41d981daa537fe6/django/db/models/fields/__init__.py#L196-L205
>
> The proposed change, then, would be to change methods like the following
> to yield their items instead of creating and returning a list:
> https://github.com/django/django/blob/f331eba6d576752dd79c4b37c41d981daa537fe6/django/db/models/fields/__init__.py#L243-L254

New description:

 I noticed that many of the internal "check()" methods used by `Field`
 subclasses return lists (including the empty list) when they can just
 yield items (or yield nothing). This is because the concrete `check()`
 implementations unpack the return value when constructing a new list. See
 here for one example of such a `check()` method:
 
https://github.com/django/django/blob/f331eba6d576752dd79c4b37c41d981daa537fe6/django/db/models/fields/__init__.py#L196-L205

 The proposed change, then, would be to change methods like the following
 to yield their items instead of creating and returning a list:
 
https://github.com/django/django/blob/f331eba6d576752dd79c4b37c41d981daa537fe6/django/db/models/fields/__init__.py#L243-L254

 It looks like there are 23 methods in that file with a name starting with
 `_check...`.

--

-- 
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.7ee04a73289870dbece34613857695b4%40djangoproject.com.

Re: [Django] #32972: Django ORM raw query not playing nice with Geometric Point objects

[Django]

#32972: Django ORM raw query not playing nice with Geometric Point objects
-+-
 Reporter:  Donovan  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  ORM raw query| Triage Stage:
  geometric location point   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Donovan):

 * Attachment "incorrect Point objects.png" added.

 Showing what the point objects look like with a .objects.raw()
 query look like when doing a print(vars(object))

-- 
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/072.6247e4718632370ff8cd6bff07f23bbb%40djangoproject.com.

[Django] #32972: Django ORM raw query not playing nice with Geometric Point objects

[Django]

#32972: Django ORM raw query not playing nice with Geometric Point objects
-+-
   Reporter:  Donovan|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  GIS|Version:  3.2
   Severity:  Normal |   Keywords:  ORM raw query
   Triage Stage: |  geometric location point
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using .objects.all() the behavior works as intended and I am
 able to get the Geometric Point object with the latitude and longitude
 correct.
 When using .objects.raw() the Point object has incorrect latitude
 and longitude -- it has scientific notation and completely different
 numbers.

-- 
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/057.9eaee7f309b52702cb2a8720803df814%40djangoproject.com.

[Django] #32971: Internal Field.check() methods don't need to construct and return lists

[Django]

#32971: Internal Field.check() methods don't need to construct and return lists
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  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  |
-+-
 I noticed that many of the internal "check()" methods used by `Field`
 subclasses return lists (including the empty list) when they can just
 yield items (or yield nothing). This is because the concrete `check()`
 implementations unpack the return value when constructing a new list. See
 here for one example of such a `check()` method:
 
https://github.com/django/django/blob/f331eba6d576752dd79c4b37c41d981daa537fe6/django/db/models/fields/__init__.py#L196-L205

 The proposed change, then, would be to change methods like the following
 to yield their items instead of creating and returning a list:
 
https://github.com/django/django/blob/f331eba6d576752dd79c4b37c41d981daa537fe6/django/db/models/fields/__init__.py#L243-L254

-- 
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/052.dff3df658ac5a07afe002a12b4ed4121%40djangoproject.com.

Re: [Django] #32966: time-related _check_fix_default_value() methods can be optimized / simplified

[Django]

#32966: time-related _check_fix_default_value() methods can be optimized /
simplified
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 |  Jerdonek
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (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 Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14717

-- 
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.c1b6b989070039755150f8db4ac3678c%40djangoproject.com.

Re: [Django] #31503: Moving a unique constraint from unique_together to Field.unique generate an invalid migration.

[Django]

#31503: Moving a unique constraint from unique_together to Field.unique 
generate an
invalid migration.
-+-
 Reporter:  Xiang Wang   |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  unique_together  | Triage Stage:  Accepted
  unique migrations  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (added)
 * owner:  nobody => David Wobrock
 * status:  new => assigned


Comment:

 Hi!

 I looked a bit into the issue. I'll share my thoughts and suggest/discuss
 some solutions so that we can agree on the approach. I'd be more than
 happy to tackle the issue then, if that is okay, once we know how we want
 to fix the issue :D

 TL;DR: some suboptimal solutions are presented, but 5/ and 6/ look the
 most promising to me. Please let's discuss those a bit at least :)

 ---

 So the issue occurs because we are changing an `unique_together` to a
 `unique=True` on the field (similarly, I believe the bug occurs with
 `index_together` and `db_index`), which will first try to create an
 existing index before deleting it.

 Some solutions:

 1/ Changing the index name

 > I think changing the format of index name if the CONSTRAINT is create by
 the unique_together will work either.
 It would somehow work and mitigate the issue at hand, but it might
 introduce complexity for backward compatibility. When upgrading your
 Django version and wanting to drop an index, Django will have to know
 whether the name of the index comes the previous or current version of
 Django, in order to know how the index is called and drop it.

 2/ Forbid using `unique_together` (and `index_together`) with a single
 field

 > If a user set unique_together containing only one field, we can raise an
 error and ask him to use unique=True instead

 It feels more like a workaround than a real fix of the issue. And more
 generally, we will have issues with backward compatibility. We can't break
 `unique_together`s with one field from a release to the next. I guess we
 would need to add a deprecation warning, and really introduce a breaking
 behaviour in the next major release (Django 5.x then?). Which seems IMHO
 like a lot of trouble for a rather narrow issue.

 3/ Leverage the existing `foo_together_change` dependency mecanism
 The autodetector has a similar re-order behaviour so the one we would need
 already implemented. When dropping a field, we add a dependency called
 `foo_together_change` to the field, which would re-order the
 `AlterUniqueTogether` operations, for the index to be dropped before the
 removal of the field.
 I tried it out for field altering (see code block below), and it would fix
 the issue at hand, but it wouldn't fix the reverse operation. If we
 changed from a `unique=True` to a `unique_together`, the dependency would
 still re-order the `AlterUniqueTogether` operation to happen before the
 `AlterField`, but we would need to first drop the index through the
 `AlterField`.
 So the very same issue occurs, just the other way around.

 {{{
 diff --git a/django/db/migrations/autodetector.py
 b/django/db/migrations/autodetector.py
 index 2848adce7d..598d4649e9 100644
 --- a/django/db/migrations/autodetector.py
 +++ b/django/db/migrations/autodetector.py
 @@ -987,7 +987,9 @@ class MigrationAutodetector:
  field=field,
  preserve_default=preserve_default,
  ),
 -dependencies=dependencies,
 +dependencies=dependencies + [
 +(app_label, model_name, field_name,
 "foo_together_change"),
 +],
  )
  else:
  # We cannot alter between m2m and concrete fields
 }}}

 4/ Split the index dropping/creation out of the AlterField operation

 The bug seems related to the fact that `AlterField` does a lot of things,
 and among them is the creation/drop of indexes, which can clash with other
 structures.
 So one could probably move this part out of `AlterField`, but it feels
 like a very heavy and error-prone change to a part that is currently core
 to the autodetector and migrations framework.
 This idea is a long-shot, and also pretty vague in my head. I wouldn't
 actually consider this solution.

 5/ Do multi-step AlterFooTogether operations

 This solution, 

Re: [Django] #32880: Improve logging documentation

[Django]

#32880: Improve logging documentation
-+-
 Reporter:  Daniele Procida  |Owner:  Daniele
 Type:   |  Procida
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  logging  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"f331eba6d576752dd79c4b37c41d981daa537fe6" f331eba6]:
 {{{
 #!CommitTicketReference repository=""
 revision="f331eba6d576752dd79c4b37c41d981daa537fe6"
 Refs #32880 -- Made remaining titles consistent in how-to documents.

 Follow up to 22fbebc7444c8974f101c146f0fc18fe64ab48f6.
 }}}

-- 
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.f71a54d76b13b3668e39075727e6909d%40djangoproject.com.

Re: [Django] #32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and request.csrf_cookie_needs_reset can be combined

[Django]

#32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and
request.csrf_cookie_needs_reset can be combined
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  CSRF |  Version:  dev
 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 Mariusz Felisiak ):

 In [changeset:"7c30bdbdb16204970cc320f4345b8a439d8f65b4" 7c30bdb]:
 {{{
 #!CommitTicketReference repository=""
 revision="7c30bdbdb16204970cc320f4345b8a439d8f65b4"
 Refs #32916 -- Replaced request.csrf_cookie_needs_reset with
 request.META['CSRF_COOKIE_NEEDS_UPDATE'].
 }}}

-- 
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.e456af108c546d11bc169a58958b6e36%40djangoproject.com.

Re: [Django] #32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and request.csrf_cookie_needs_reset can be combined

[Django]

#32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and
request.csrf_cookie_needs_reset can be combined
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  CSRF |  Version:  dev
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"6ebf931de8926d88db6d2684cb07d1bbebb919a5" 6ebf931d]:
 {{{
 #!CommitTicketReference repository=""
 revision="6ebf931de8926d88db6d2684cb07d1bbebb919a5"
 Fixed #32916 -- Combined request.META['CSRF_COOKIE_USED'] and
 request.csrf_cookie_needs_reset.
 }}}

-- 
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.0b5db241497144731735cbf9ec885ddc%40djangoproject.com.

Re: [Django] #32970: Investigate feasibility of improving WhereNode clone performance

[Django]

#32970: Investigate feasibility of improving WhereNode clone performance
-+-
 Reporter:  Keryn Knight |Owner:  Keryn
 Type:   |  Knight
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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
-+-
Description changed by Keryn Knight:

Old description:

> This relates to #32948 insofar as it's about figuring out how shallow or
> deep a copy is necessary for cloning `Node` instances/subclasses. And a
> bit to #28455 which acknowledges the need to avoid cloning sometimes due
> to it being costly.
>
> The PR I made for optimising Q combining/inverting
> (https://github.com/django/django/pull/14673) wants to introduce a
> `__copy__` method onto `Q` objects to indicate what level of operation is
> needed. Unlike that PR, it's decidedly not possible to take the same
> approach with WhereNode and just do `clone.__dict__ =
> self.__dict__.copy()` (things broke horribly) because of attributes like
> `contains_aggregate` and `output_field` which are cached properties on
> the WhereNode instance. Also `resolved` gets set after the fact by
> `resolve_expression`. But, as far as I can tell, the
> looping/testing/child cloning ''may be removable''. Perhaps once upon a
> time they were required and other components changed such that it's now
> safe to consider. I can't readily say, but initial experimentation
> suggests it's OK to look at, at least in theory.
>
> There is a PR already for this, here:
> https://github.com/django/django/pull/14709 which is currently marked
> draft/WIP because I couldn't easily run the whole test suite locally and
> needed to see if the more exotic parts caused problems. They didn't,
> which was unexpected, so here I am. The PR currently replaces the
> `WhereNode.clone` method like so:
> {{{
> clone = self.__class__._new_instance(children=[],
> connector=self.connector, negated=self.negated)
> for child in self.children:
> if hasattr(child, 'clone'):
> clone.children.append(child.clone())
> else:
> clone.children.append(child)
> }}}
> with:
> {{{
> clone = self.__class__._new_instance(children=None,
> connector=self.connector, negated=self.negated)
> clone.children = self.children[:]
> }}}
>

> But I ''think'' that Q and WhereNode ''can'' both just return a shallow
> copy by only aliasing the children property, at which point I think the
> `__copy__` method could be implemented on `Node` directly and mirror the
> existing `__deepcopy__` method. By preferring those stdlib names it draws
> a line in the sand over what level of copy should be expected. The
> existing `clone` and `copy` methods can become aliases to same.
>

> === Before any changes
>
> If we now begin to examine the before and after with as much data as I
> can easily gather. First a bit of prelude:
>
> {{{
> In [1]: from django.db.models.sql.where import WhereNode
> In [2]: from django.db.models import QuerySet
> In [3]: from django.db.models.sql import Query
> In [4]: from django.contrib.auth.models import User
> In [5]: x = User.objects.all()
> In [6]: y = User.objects.filter(username='test',
> email='t...@test.test').exclude(username='test').filter(email='nottest')
> In [7]: %load_ext line_profiler
> }}}
>
> Now let's establish a ballpark for how much time is spent where, I've
> stripped the line profiling down to just the relevant bits for clarity.
>
>  Queryset with no clauses (`x`)
>
> {{{
> In [8]: %lprun -f QuerySet._chain -f QuerySet._clone -f Query.chain -f
> Query.clone -f WhereNode.clone for _ in range(1000): x._chain()
>
> Function: QuerySet._chain
> Line #  Hits Time  Per Hit   % Time  Line Contents
> ==
>   1325   def _chain(self,
> **kwargs):
>   ...
>   1330  1000  88169.0 88.2 97.8  obj =
> self._clone()
>
> Function: QuerySet._clone
> Line #  Hits Time  Per Hit   % Time  Line Contents
> ==
>   1337   def _clone(self):
>   ...
>   1342  1000  80796.0 80.8 86.3  chained =
> self.query.chain()
>   1343  1000   7240.0  7.2  7.7  c =
> self.__class__(model=self.model, query=chained, 

[Django] #32970: Investigate feasibility of improving WhereNode clone performance

[Django]

#32970: Investigate feasibility of improving WhereNode clone performance
-+-
   Reporter:  Keryn  |  Owner:  Keryn Knight
  Knight |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Database   |Version:  dev
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This relates to #32948 insofar as it's about figuring out how shallow or
 deep a copy is necessary for cloning `Node` instances/subclasses. And a
 bit to #28455 which acknowledges the need to avoid cloning sometimes due
 to it being costly.

 The PR I made for optimising Q combining/inverting
 (https://github.com/django/django/pull/14673) wants to introduce a
 `__copy__` method onto `Q` objects to indicate what level of operation is
 needed. Unlike that PR, it's decidedly not possible to take the same
 approach with WhereNode and just do `clone.__dict__ =
 self.__dict__.copy()` (things broke horribly) because of attributes like
 `contains_aggregate` and `output_field` which are cached properties on the
 WhereNode instance. Also `resolved` gets set after the fact by
 `resolve_expression`. But, as far as I can tell, the looping/testing/child
 cloning ''may be removable''. Perhaps once upon a time they were required
 and other components changed such that it's now safe to consider. I can't
 readily say, but initial experimentation suggests it's OK to look at, at
 least in theory.

 There is a PR already for this, here:
 https://github.com/django/django/pull/14709 which is currently marked
 draft/WIP because I couldn't easily run the whole test suite locally and
 needed to see if the more exotic parts caused problems. They didn't, which
 was unexpected, so here I am. The PR currently replaces the
 `WhereNode.clone` method like so:
 {{{
 clone = self.__class__._new_instance(children=[],
 connector=self.connector, negated=self.negated)
 for child in self.children:
 if hasattr(child, 'clone'):
 clone.children.append(child.clone())
 else:
 clone.children.append(child)
 }}}
 with:
 {{{
 clone = self.__class__._new_instance(children=None,
 connector=self.connector, negated=self.negated)
 clone.children = self.children[:]
 }}}


 But I ''think'' that Q and WhereNode ''can'' both just return a shallow
 copy by only aliasing the children property, at which point I think the
 `__copy__` method could be implemented on `Node` directly and mirror the
 existing `__deepcopy__` method. By preferring those stdlib names it draws
 a line in the sand over what level of copy should be expected. The
 existing `clone` and `copy` methods can become aliases to same.


 === Before any changes

 If we now begin to examine the before and after with as much data as I can
 easily gather. First a bit of prelude:

 {{{
 In [1]: from django.db.models.sql.where import WhereNode
 In [2]: from django.db.models import QuerySet
 In [3]: from django.db.models.sql import Query
 In [4]: from django.contrib.auth.models import User
 In [5]: x = User.objects.all()
 In [6]: y = User.objects.filter(username='test',
 email='t...@test.test').exclude(username='test').filter(email='nottest')
 In [7]: %load_ext line_profiler
 }}}

 Now let's establish a ballpark for how much time is spent where, I've
 stripped the line profiling down to just the relevant bits for clarity.

  Queryset with no clauses (`x`)

 {{{
 In [8]: %lprun -f QuerySet._chain -f QuerySet._clone -f Query.chain -f
 Query.clone -f WhereNode.clone for _ in range(1000): x._chain()

 Function: QuerySet._chain
 Line #  Hits Time  Per Hit   % Time  Line Contents
 ==
   1325   def _chain(self,
 **kwargs):
   ...
   1330  1000  88169.0 88.2 97.8  obj =
 self._clone()

 Function: QuerySet._clone
 Line #  Hits Time  Per Hit   % Time  Line Contents
 ==
   1337   def _clone(self):
   ...
   1342  1000  80796.0 80.8 86.3  chained =
 self.query.chain()
   1343  1000   7240.0  7.2  7.7  c =
 self.__class__(model=self.model, query=chained, using=self._db,
 hints=self._hints))

 Function: Query.chain
 Line #  Hits Time  Per Hit   % Time  Line Contents
 ==
341   

Re: [Django] #32855: BoundWidget.id_for_label ignores id set by ChoiceWidget.options

[Django]

#32855: BoundWidget.id_for_label ignores id set by ChoiceWidget.options
-+-
 Reporter:  Jacob Rief   |Owner:  Jacob
 |  Rief
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  auto_id, | Triage Stage:  Ready for
  id_for_label   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by ᴙɘɘᴙgYmɘᴙɘj):

 * stage:  Accepted => Ready for checkin


Comment:

 The regression test looks good; fails before fix, passes afterward.

 I don't think this one
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /submitting-patches/#bugs qualifies for a backport], so I'm changing it to
 "Ready for checkin."

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

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

Re: [Django] #32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text search.

[Django]

#32492: Add django API for Postgres pg_trgm word_similarity, fuzzy full-text
search.
--+
 Reporter:  Taneli|Owner:  Taneli
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  dev
 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 Matthew Schinckel):

 FWIW, I use pg_trgm, and I also have a `connection_created` receiver that
 sets `pg_trgm.similarity_threshold`. It might be nice to include the
 ability to set this in some way, so that other operations that use this
 can be included.

-- 
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.d62d733532d80602712f4e7c32391318%40djangoproject.com.

Re: [Django] #32880: Improve logging documentation

[Django]

#32880: Improve logging documentation
-+-
 Reporter:  Daniele Procida  |Owner:  Daniele
 Type:   |  Procida
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  logging  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


-- 
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.4fb4cf846308eaa9c8aaff5f9800990b%40djangoproject.com.

Re: [Django] #32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and request.csrf_cookie_needs_reset can be combined

[Django]

#32916: CsrfViewMiddleware's request.META["CSRF_COOKIE_USED"] and
request.csrf_cookie_needs_reset can be combined
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 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 Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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