Re: [Django] #27844: Add a management command to optimize a migration

[Django]

#27844: Add a management command to optimize a migration
-+-
 Reporter:  Raphael Gaschignard  |Owner:  David
 |  Wobrock
 Type:  New feature  |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


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

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

Re: [Django] #33518: Add alias RemovedAfterNextVersionWarning for deprecations after next version

[Django]

#33518: Add alias RemovedAfterNextVersionWarning for deprecations after next
version
-+-
 Reporter:  Shai Berger  |Owner:
 Type:   |  Saidblanchette
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 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
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:4 Shai Berger]:
 > Replying to [comment:2 Mariusz Felisiak]:
 > > I'm not sure about the name. What do you think about
 `RemovedInVersionAfterNextWarning`?
 >
 > I started with `RemovedInNextNextVersionWarning` and changed it when I
 realized that is incorrect for x.0 versions (the pending-deprecation
 warning is not about the x.2 version, but about the (x+1).0 version). As
 far as my English goes, that also disqualifies
 `RemovedInVersionAfterNextWarning`.

 Right 

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

Re: [Django] #33518: Add alias RemovedAfterNextVersionWarning for deprecations after next version

[Django]

#33518: Add alias RemovedAfterNextVersionWarning for deprecations after next
version
-+-
 Reporter:  Shai Berger  |Owner:
 Type:   |  Saidblanchette
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 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
-+-

Comment (by Shai Berger):

 Replying to [comment:2 Mariusz Felisiak]:
 > I'm not sure about the name. What do you think about
 `RemovedInVersionAfterNextWarning`?

 I started with `RemovedInNextNextVersionWarning` and changed it when I
 realized that is incorrect for x.0 versions (the pending-deprecation
 warning is not about the x.2 version, but about the (x+1).0 version). As
 far as my English goes, that also disqualifies
 `RemovedInVersionAfterNextWarning`.

 > Would you like to provide a patch?

 I'm happy to see that someone has already taken it upon themselves. Good
 luck, Saidblanchette!

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

Re: [Django] #33518: Add alias RemovedAfterNextVersionWarning for deprecations after next version

[Django]

#33518: Add alias RemovedAfterNextVersionWarning for deprecations after next
version
-+-
 Reporter:  Shai Berger  |Owner:
 Type:   |  Saidblanchette
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 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 Saidblanchette):

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


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

Re: [Django] #28897: QuerySet.update() raises FieldError on queryset ordered by an annotated field.

[Django]

#28897: QuerySet.update() raises FieldError on queryset ordered by an annotated
field.
-+-
 Reporter:  Colton Hicks |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Admin Interface, | Triage Stage:  Accepted
  Custom Action, Annotated Field,|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Saidblanchette):

 Hi, guys I'd love to work in this, any suggestions ! I need help to
 understand this more and what can you do next

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

Re: [Django] #23916: makemigrations does not detect/like model name case changes

[Django]

#23916: makemigrations does not detect/like model name case changes
-+-
 Reporter:  Sven Coenye  |Owner:  Adam Johnson
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  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:"760b7e7f4f62eafdc79a2188d2a7739abaa6ca8b" 760b7e7f]:
 {{{
 #!CommitTicketReference repository=""
 revision="760b7e7f4f62eafdc79a2188d2a7739abaa6ca8b"
 [4.0.x] Fixed #33515 -- Prevented recreation of migration for
 ManyToManyField to lowercased swappable setting.

 Thanks Chris Lee for the report.

 Regression in 43289707809c814a70f0db38ca4f82f35f43dbfd.

 Refs #23916.
 Backport of 1e2e1be02bdf0fe4add0d0279dbca1d74ae28ad7 from main
 }}}

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

Re: [Django] #33515: ManyToManyField to lowercased swappable setting causes generating infinite migrations.

[Django]

#33515: ManyToManyField to lowercased swappable setting causes generating 
infinite
migrations.
-+-
 Reporter:  Chris Lee|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  M2M migration user   | Triage Stage:  Accepted
  manytomany |
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:"760b7e7f4f62eafdc79a2188d2a7739abaa6ca8b" 760b7e7f]:
 {{{
 #!CommitTicketReference repository=""
 revision="760b7e7f4f62eafdc79a2188d2a7739abaa6ca8b"
 [4.0.x] Fixed #33515 -- Prevented recreation of migration for
 ManyToManyField to lowercased swappable setting.

 Thanks Chris Lee for the report.

 Regression in 43289707809c814a70f0db38ca4f82f35f43dbfd.

 Refs #23916.
 Backport of 1e2e1be02bdf0fe4add0d0279dbca1d74ae28ad7 from main
 }}}

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

Re: [Django] #23916: makemigrations does not detect/like model name case changes

[Django]

#23916: makemigrations does not detect/like model name case changes
-+-
 Reporter:  Sven Coenye  |Owner:  Adam Johnson
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  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 GitHub ):

 In [changeset:"1e2e1be02bdf0fe4add0d0279dbca1d74ae28ad7" 1e2e1be]:
 {{{
 #!CommitTicketReference repository=""
 revision="1e2e1be02bdf0fe4add0d0279dbca1d74ae28ad7"
 Fixed #33515 -- Prevented recreation of migration for ManyToManyField to
 lowercased swappable setting.

 Thanks Chris Lee for the report.

 Regression in 43289707809c814a70f0db38ca4f82f35f43dbfd.

 Refs #23916.
 }}}

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

Re: [Django] #33515: ManyToManyField to lowercased swappable setting causes generating infinite migrations.

[Django]

#33515: ManyToManyField to lowercased swappable setting causes generating 
infinite
migrations.
-+-
 Reporter:  Chris Lee|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  M2M migration user   | Triage Stage:  Accepted
  manytomany |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"1e2e1be02bdf0fe4add0d0279dbca1d74ae28ad7" 1e2e1be]:
 {{{
 #!CommitTicketReference repository=""
 revision="1e2e1be02bdf0fe4add0d0279dbca1d74ae28ad7"
 Fixed #33515 -- Prevented recreation of migration for ManyToManyField to
 lowercased swappable setting.

 Thanks Chris Lee for the report.

 Regression in 43289707809c814a70f0db38ca4f82f35f43dbfd.

 Refs #23916.
 }}}

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

Re: [Django] #33518: Add alias RemovedAfterNextVersionWarning for deprecations after next version

[Django]

#33518: Add alias RemovedAfterNextVersionWarning for deprecations after next
version
--+
 Reporter:  Shai Berger   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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 Mariusz Felisiak):

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


Comment:

 Sounds reasonable, I'm not sure about the name. What do you think about
 `RemovedInVersionAfterNextWarning`? Would you like to provide a 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.842eb41546ddd0038fd5754b43c4c8a0%40djangoproject.com.

Re: [Django] #28358: LazyObject defines attribute that don't exist on wrapped object

[Django]

#28358: LazyObject defines attribute that don't exist on wrapped object
-+-
 Reporter:  Andrey Fedoseev  |Owner:  Theofilos
 |  Alexiou
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  1.11
 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:"97d7990abde3fe4b525ae83958fd0b52d6a1d13f" 97d7990a]:
 {{{
 #!CommitTicketReference repository=""
 revision="97d7990abde3fe4b525ae83958fd0b52d6a1d13f"
 Fixed #28358 -- Prevented LazyObject from mimicking nonexistent
 attributes.

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

Re: [Django] #33267: Add Hyperlink to related model in admin change form.

[Django]

#33267: Add Hyperlink to related model in admin change form.
+
 Reporter:  Thomas Güttler  |Owner:  Shubh Parmar
 Type:  New feature |   Status:  assigned
Component:  contrib.admin   |  Version:  3.2
 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 Shubh Parmar):

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


Comment:

 I have made the required changes. Can someone review the PR?

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

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

Re: [Django] #33518: Add alias RemovedAfterNextVersionWarning for deprecations after next version

[Django]

#33518: Add alias RemovedAfterNextVersionWarning for deprecations after next
version
-+-
 Reporter:  Shai Berger  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by Shai Berger:

Old description:

> For a very long time, we've had in {{{django.utils.deprecation}}}
> something like this (from the 3.2 source code):
> {{{#!python
> class RemovedInDjango40Warning(DeprecationWarning):
> pass
>

> class RemovedInDjango41Warning(PendingDeprecationWarning):
> pass
>

> RemovedInNextVersionWarning = RemovedInDjango40Warning
> }}}
> Or (current master, towards 4.1):
> {{{#!python
> class RemovedInNextVersionWarning(DeprecationWarning):
> pass
>

> class RemovedInDjango50Warning(PendingDeprecationWarning):
> pass
> }}}
>
> I suggest that we add an alias, {{{RemovedAfterNextVersion}}} for the
> {{{PendingDeprecationWarning}}} subclass.
>
> The motivation is to make it easier for long-running projects to prepare
> for future deprecations, with scripts that run tests with special filters
> on the relevant warnings; currently, such scripts need to be updated for
> every version. This is especially important for projects which stick to
> LTS versions, as for them, both warnings need to be treated the same.

New description:

 For a very long time, we've had in {{{django.utils.deprecation}}}
 something like this (from the 3.2 source code):
 {{{#!python
 class RemovedInDjango40Warning(DeprecationWarning):
 pass


 class RemovedInDjango41Warning(PendingDeprecationWarning):
 pass


 RemovedInNextVersionWarning = RemovedInDjango40Warning
 }}}
 Or (current master, towards 4.1):
 {{{#!python
 class RemovedInNextVersionWarning(DeprecationWarning):
 pass


 class RemovedInDjango50Warning(PendingDeprecationWarning):
 pass
 }}}

 I suggest that we add an alias, {{{RemovedAfterNextVersionWarning}}} for
 the {{{PendingDeprecationWarning}}} subclass.

 The motivation is to make it easier for long-running projects to prepare
 for future deprecations, with scripts that run tests with special filters
 on the relevant warnings; currently, such scripts need to be updated for
 every version. This is especially important for projects which stick to
 LTS versions, as for them, both warnings need to be treated the same.

--

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

[Django] #33518: Add alias RemovedAfterNextVersionWarning for deprecations after next version

[Django]

#33518: Add alias RemovedAfterNextVersionWarning for deprecations after next
version
+
   Reporter:  Shai Berger   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Other)  |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 For a very long time, we've had in {{{django.utils.deprecation}}}
 something like this (from the 3.2 source code):
 {{{#!python
 class RemovedInDjango40Warning(DeprecationWarning):
 pass


 class RemovedInDjango41Warning(PendingDeprecationWarning):
 pass


 RemovedInNextVersionWarning = RemovedInDjango40Warning
 }}}
 Or (current master, towards 4.1):
 {{{#!python
 class RemovedInNextVersionWarning(DeprecationWarning):
 pass


 class RemovedInDjango50Warning(PendingDeprecationWarning):
 pass
 }}}

 I suggest that we add an alias, {{{RemovedAfterNextVersion}}} for the
 {{{PendingDeprecationWarning}}} subclass.

 The motivation is to make it easier for long-running projects to prepare
 for future deprecations, with scripts that run tests with special filters
 on the relevant warnings; currently, such scripts need to be updated for
 every version. This is especially important for projects which stick to
 LTS versions, as for them, both warnings need to be treated the same.

-- 
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/048.d80adf7f9a7fea55da84748ac4d3fbd3%40djangoproject.com.

[Django] #33517: Implied behavior of `__second` extractor inside of `F()` expressions does not match documented behavior for at least PostgreSQL

[Django]

#33517: Implied behavior of `__second` extractor inside of `F()` expressions 
does
not match documented behavior for at least PostgreSQL
-+
   Reporter:  josefdlange|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  4.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  |
-+
 In the Django documentation
 (https://docs.djangoproject.com/en/4.0/ref/models/querysets/#second) the
 `__second` extractor is implied to be dealing with integer values for
 second in a date time. In at least PostgreSQL, the values from
 `EXTRACT`ing `second` from a date time will include "any fractional
 seconds" (https://www.postgresql.org/docs/current/functions-datetime.html
 #FUNCTIONS-DATETIME-EXTRACT) which means it could be more specific than an
 integer.

 Because of the implication in Django's documentation, I had expected this
 filter to work as expected for a row whose `date_created` and
 `date_modified` are within a second of each other but a couple of
 milliseconds off:

 `.filter(date_created__second=F("date_modified__second"))`

 However, that ends up not being true given the Postgres behavior.

 My recommendation is merely a documentation update to highlight the
 discrepancy of behavior between a value coalesced to Python from the DB
 data, and how the column values are perceived on the database side within
 a query. I'm struggling for adequate language to explain in such a
 context, though :-P happy to discuss further and work together toward this
 improvement.

-- 
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/054.e5b88dcddc58965c1b0ab1d9682bd84a%40djangoproject.com.

Re: [Django] #33516: QuerySet update() under postgres with select_for_update(skip_locked=True) results in neither FOR UPDATE nor SKIP LOCKED

[Django]

#33516: QuerySet update() under postgres with 
select_for_update(skip_locked=True)
results in neither FOR UPDATE nor SKIP LOCKED
-+-
 Reporter:  Grant Gainey |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Grant Gainey):

 Ah-ha! Perfect, that explains everything!

 Two comments/suggestions:
 * Could it be possible for select_for_update() to throw an exception when
 it's not going to be emitted? Would have helped me target the problem way
 sooner if the method yelled at me for using it incorrectly
 * Similarly - when called 'correctly', select_for_update() throws an
 exception if you're not in a transaction. When called incorrectly, it
 doesn't. Would be great if the behavior was consistent.

 For posterity's sake, below is my test-script using the suggested changes,
 that works on a 20K table with no deadlocks. Thanks for the pointer!

 {{{
 import statistics
 import time
 from threading import Thread
 from pulpcore.app.models import Content
 from django.db import transaction
 from django.utils.timezone import now

 durations = []

 def update_timestamp(index):

 print(">>>in update_timedstamp index {}".format(index))
 start = time.time()
 with transaction.atomic():
 content_q = (
 Content.objects.filter()
 .order_by("pk")
 .select_for_update(skip_locked=True)
 .values_list("pk", flat=True)
 )
 Content.objects.filter(pk__in=content_q).update(timestamp_of_interest=now())
 end = time.time()
 durations.append(end-start)
 print(">>>done")

 for r in range(10):
 threads = []
 for i in range(10):
 threads.append(Thread(target=update_timestamp, args=(i,)))
 for t in threads:
 t.start()
 for t in threads:
 t.join()

 print("Avg time : {}".format(sum(durations) / len(durations)))
 print("Median time : {}".format(statistics.median(durations)))
 print("StdDev : {}".format(statistics.stdev(durations)))
 }}}

 And the emitted SQL:
 {{{
 2022-02-16 13:46:02.517 UTC [368804] LOG:  statement: UPDATE
 "core_content" SET "timestamp_of_interest" =
 '2022-02-16T13:46:02.516956+00:00'::timestamptz WHERE
 "core_content"."pulp_id" IN (SELECT U0."pulp_id" FROM "core_content" U0
 ORDER BY U0."pulp_id" ASC FOR UPDATE SKIP LOCKED)
 }}}

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

Re: [Django] #33508: MariaDB 10.8+ supports ordering on individual columns in the index.

[Django]

#33508: MariaDB 10.8+ supports ordering on individual columns in the index.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Alokik
 Type:   |  Roy
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mariadb  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alokik Roy):

 * cc: Alokik Roy (added)
 * owner:  nobody => Alokik Roy
 * status:  new => assigned


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

Re: [Django] #28358: LazyObject defines attribute that don't exist on wrapped object

[Django]

#28358: LazyObject defines attribute that don't exist on wrapped object
-+-
 Reporter:  Andrey Fedoseev  |Owner:  Theofilos
 |  Alexiou
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  1.11
 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/072.fa306e77e238c955fc0355ea70df0585%40djangoproject.com.

Re: [Django] #27471: Make admin's list_filter choices collapsable

[Django]

#27471: Make admin's list_filter choices collapsable
-+-
 Reporter:  Greg McCoy   |Owner:  Marcelo
 |  Galigniana
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  filter admin | Triage Stage:  Accepted
  collaspe   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #11803: Admin does not update every ForeignKey select of the same model

[Django]

#11803: Admin does not update every ForeignKey select of the same model
-+-
 Reporter:  danilo   |Owner:  Marcelo
   |  Galigniana
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  admin select | Triage Stage:  Accepted
  foreignkey |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 The suggest patch looks kind of neat, so 
 I think `limit_choices_to` (and maybe other wiggles) need consideration
 for it to be 100%

-- 
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/091.59e0f8fbb28b5ff25024defd00ccba7c%40djangoproject.com.

Re: [Django] #33515: ManyToManyField to lowercased swappable setting causes generating infinite migrations.

[Django]

#33515: ManyToManyField to lowercased swappable setting causes generating 
infinite
migrations.
-+-
 Reporter:  Chris Lee|Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  M2M migration user   | Triage Stage:  Accepted
  manytomany |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

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

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

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