Re: [Django] #30947: Apply data structure best practices to the django.contrib models and docs

[Django]

#30947: Apply data structure best practices to the django.contrib models and 
docs
-+-
 Reporter:  Jon Dufresne |Owner:  Ojas
 Type:   |  Gupta
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Alex Morega):

 > Some of the examples you pointed should remain tuples as they are mixing
 heterogenous data and mostly used to a define a schema over data.

 Right! I meant it as a starting point of places that might need fixing.

 > Since we're on the topic of data structure best practices
 `unique_together` and friends should likely be defined as `set` and not
 `list` as only unique entries will be considered and because the order in
 which they are defined on the model doesn't have any significance.

 I see your point, but AFAIU, a side effect of `unique_together` is
 creating composite database indexes, where the
 [https://www.postgresql.org/docs/current/indexes-multicolumn.html order of
 columns matters].

 There hasn't been any activity on the ticket for 3 weeks; may I take
 ownership?

-- 
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/01070182c4788a5e-e3d37947-771d-4a87-8603-d08363fb56e6-00%40eu-central-1.amazonses.com.

Re: [Django] #33939: Change docs for transaction.on_commit to suggest functools.partial instead of lambda

[Django]

#33939: Change docs for transaction.on_commit to suggest functools.partial 
instead
of lambda
--+
 Reporter:  Alex Morega   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  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
--+
Changes (by Carlton Gibson):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Hey Alex. OK... I might be a bit marginal but, certainly happy to look at
 a PR if you're keen to make it.

-- 
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/01070182c479d51a-7fac9db9-98f0-4907-8cf9-ca65dfd3121d-00%40eu-central-1.amazonses.com.

Re: [Django] #33944: Is it cleaner to make the upload_to function a method of the model class

[Django]

#33944: Is it cleaner to make the upload_to function a method of the model class
--+--
 Reporter:  Willem Van Onsem  |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Documentation |  Version:  dev
 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
--+--
Changes (by Carlton Gibson):

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


Comment:

 Hi Willem. I think you're likely free to do that, but I think questions
 such as this are better targeted at support channels. See
 TicketClosingReasons/UseSupportChannels.
 (I don't think it's a change we need to enforce, or favour in the docs
 even.)

-- 
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/01070182c47c9146-909b90c8-f6ef-4daf-a2f5-46bd6065dc66-00%40eu-central-1.amazonses.com.

Re: [Django] #33939: Change docs for transaction.on_commit to suggest functools.partial instead of lambda

[Django]

#33939: Change docs for transaction.on_commit to suggest functools.partial 
instead
of lambda
-+-
 Reporter:  Alex Morega  |Owner:  Alex
 Type:   |  Morega
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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
-+-
Changes (by Alex Morega):

 * owner:  nobody => Alex Morega
 * 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/01070182c47ffc85-c4187a50-2414-4160-bfad-9ecf49ded908-00%40eu-central-1.amazonses.com.

Re: [Django] #33942: file validator - validating file with mime and magic numbers

[Django]

#33942: file validator - validating file with mime and magic numbers
-+-
 Reporter:  Reza Shakeri |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  4.0
  uploads/storage|
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  file-validator,  | Triage Stage:
  file, validator|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Reza.

 You've marked this as a new feature, so I guess you want to include this
 in core. I'll say no at first pass, since complicating the built-in
 validators isn't really on the agenda.
 Folks are very able to create their own, as you've done here. There'd need
 to be a consensus to include more logic here via a discussion on the
 DevelopersMailingList.

 You can also tell folks about your validator on the
 [https://forum.djangoproject.com/c/projects/11 Show & Tell category on the
 Django Forum]. (More generally see
 TicketClosingReasons/UseSupportChannels).


 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/01070182c4818941-df90b34b-a90a-45b9-910b-fecc0d3f3f2c-00%40eu-central-1.amazonses.com.

Re: [Django] #33942: file validator - validating file with mime and magic numbers

[Django]

#33942: file validator - validating file with mime and magic numbers
-+-
 Reporter:  Reza Shakeri |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  4.0
  uploads/storage|
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  file-validator,  | Triage Stage:
  file, validator|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Reza Shakeri):

 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/01070182c493aeaf-6e487d79-0d74-47ac-a563-ac444182ab18-00%40eu-central-1.amazonses.com.

Re: [Django] #33938: Defining the "through" model in a many-to-many field in another app causes "AttributeError: 'str' object has no attribute '_meta'" on migration

[Django]

#33938: Defining the "through" model in a many-to-many field in another app 
causes
"AttributeError: 'str' object has no attribute '_meta'" on migration
-+-
 Reporter:  bryan.af7|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  migration many-to-   | Triage Stage:  Ready for
  many bug   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/01070182c5b8e60f-a5c2d0f2-c8ef-4482-a88a-38f78661f2e2-00%40eu-central-1.amazonses.com.

Re: [Django] #33945: get_previous_in_order and get_next_in_order return incorrect data when objects is stored in non-default database

[Django]

#33945: get_previous_in_order and get_next_in_order return incorrect data when
objects is stored in non-default database
-+-
 Reporter:  François Granade |Owner:  Wael
 |  Ramadan
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK, I think this is valid. `Model._get_next_or_previous_in_order()`
 doesn't apply `using()` at all.
 
[https://github.com/django/django/blob/e9fd2b572410b1236da0d3d0933014138d89f44e/django/db/models/base.py#L1170-L1191
 src]

 Reproduces with the following diff:


 {{{
 diff --git a/tests/multiple_database/models.py
 b/tests/multiple_database/models.py
 index 7de784e149..4c8bdffb96 100644
 --- a/tests/multiple_database/models.py
 +++ b/tests/multiple_database/models.py
 @@ -79,3 +79,18 @@ class UserProfile(models.Model):

  class Meta:
  ordering = ("flavor",)
 +
 +
 +class Question(models.Model):
 +text = models.CharField(max_length=200)
 +
 +
 +class Answer(models.Model):
 +text = models.CharField(max_length=200)
 +question = models.ForeignKey(Question, models.CASCADE)
 +
 +class Meta:
 +order_with_respect_to = "question"
 +
 +def __str__(self):
 +return self.text
 diff --git a/tests/multiple_database/tests.py
 b/tests/multiple_database/tests.py
 index 7a9ff4da4e..8bf30c6fd9 100644
 --- a/tests/multiple_database/tests.py
 +++ b/tests/multiple_database/tests.py
 @@ -12,7 +12,7 @@ from django.db.models import signals
  from django.db.utils import ConnectionRouter
  from django.test import SimpleTestCase, TestCase, override_settings

 -from .models import Book, Person, Pet, Review, UserProfile
 +from .models import Book, Person, Pet, Review, UserProfile, Question,
 Answer
  from .routers import AuthRouter, TestRouter, WriteRouter


 @@ -2503,6 +2503,17 @@ class RouteForWriteTestCase(TestCase):
  self.assertEqual(e.model, Book)
  self.assertEqual(e.hints, {"instance": auth})

 +def test_order_with_respect_to(self):
 +q = Question.objects.using("other").create(text="The question")
 +a1 = Answer.objects.using("other").create(text="Answer 1",
 question=q)
 +a2 = Answer.objects.using("other").create(text="Answer 2",
 question=q)
 +a3 = Answer.objects.using("other").create(text="Answer 3",
 question=q)
 +q.set_answer_order([a1.pk, a2.pk, a3.pk], "other")
 +
 +a2.refresh_from_db()
 +self.assertIs(a2.get_next_in_order(), a3)
 +self.assertIs(a2.get_previous_in_order(), a1)
 +

  class NoRelationRouter:
  """Disallow all relations."""
 }}}

 Let's accept to investigate.

-- 
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/01070182c5d103c9-d616f1a9-fa48-4b13-b31a-27fffcd640f9-00%40eu-central-1.amazonses.com.

Re: [Django] #33939: Change docs for transaction.on_commit to suggest functools.partial instead of lambda

[Django]

#33939: Change docs for transaction.on_commit to suggest functools.partial 
instead
of lambda
-+-
 Reporter:  Alex Morega  |Owner:  Alex
 Type:   |  Morega
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 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 Alex Morega):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/15981 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/01070182c5e4f2fa-88be1d0d-8a3c-467f-9fc1-2b04566a9d7f-00%40eu-central-1.amazonses.com.

Re: [Django] #30947: Apply data structure best practices to the django.contrib models and docs

[Django]

#30947: Apply data structure best practices to the django.contrib models and 
docs
-+-
 Reporter:  Jon Dufresne |Owner:  Ojas
 Type:   |  Gupta
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Simon Charette):

 > I see your point, but AFAIU, a side effect of unique_together is
 creating composite database indexes, where the ​order of columns matters.

 The order of columns within an index or unique constraints matter, but the
 order of constraints doesn't. This obviously means that you can't use the
 ''flattened'' syntax `index_together = {'foo', 'bar'}` but favor
 `index_together = {('foo', 'bar')}`.

-- 
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/01070182c60e6a3e-15c3ab90-5418-4ad2-b857-ae63d402e04e-00%40eu-central-1.amazonses.com.

[Django] #33946: admin change_form field label does not use mark_safe

[Django]

#33946: admin change_form field label does not use mark_safe
-+
   Reporter:  Caram  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  4.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+
 Example:

 **models.py**
 {{{
 myfield = models.BooleanField(format_html(''))
 }}}

 **generated HTML**

 {{{
 
 }}}

 The issue only occurs for  change_form.html. In other words,
 change_list.html handles this case well.

-- 
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/01070182c67f4abe-3d9f7520-cc27-4c28-ab8c-22a3091d4237-00%40eu-central-1.amazonses.com.

Re: [Django] #32210: Django Admin with Inlines not using UUIDField default value

[Django]

#32210: Django Admin with Inlines not using UUIDField default value
--+
 Reporter:  Joseph Metzinger  |Owner:  (none)
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  3.1
 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 NeErAj KuMaR):

 The below code set id value **None** when formsets is_valid calling. so
 need to stop set id value None when that field is not model's pk as
 UUIDField.

 {{{
 if self.instance._state.adding:
 if kwargs.get("to_field") is not None:
 to_field =
 self.instance._meta.get_field(kwargs["to_field"])
 else:
 to_field = self.instance._meta.pk
 if to_field.has_default():
 setattr(self.instance, to_field.attname, None)
 }}}

-- 
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/01070182c6f6a91e-e5266323-4d62-4b69-8bb1-5295dc74c1c3-00%40eu-central-1.amazonses.com.

Re: [Django] #32210: Django Admin with Inlines not using UUIDField default value

[Django]

#32210: Django Admin with Inlines not using UUIDField default value
--+
 Reporter:  Joseph Metzinger  |Owner:  NeErAj KuMaR
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by NeErAj KuMaR):

 * owner:  (none) => NeErAj KuMaR


-- 
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/01070182c6f7dd42-23c641a2-056a-4611-a975-0e306b0eef1b-00%40eu-central-1.amazonses.com.

Re: [Django] #25234: Add an option to disable System Checks

[Django]

#25234: Add an option to disable System Checks
-+-
 Reporter:  Marcin Nowak |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  1.8
  commands)  |
 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 cknoll):

 Although this feature has been closed several years ago as *wontfix* it
 seems like it has been fixed anyway. Quoting
 [https://docs.djangoproject.com/en/4.1/ref/django-admin/#runserver]:



 {{{
  Changed in Django 4.0:

 Support for the --skip-checks option was added.

 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070182c716fdc9-97266fdf-aee4-4dd8-a3e5-2aab18646c73-00%40eu-central-1.amazonses.com.

Re: [Django] #32210: Django Admin with Inlines not using UUIDField default value

[Django]

#32210: Django Admin with Inlines not using UUIDField default value
--+
 Reporter:  Joseph Metzinger  |Owner:  Neeraj Kumar
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  3.1
 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 Neeraj Kumar):

 * has_patch:  0 => 1


Comment:

 Check PR for this issue.

 [https://github.com/django/django/pull/15983]

-- 
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/01070182c724069a-f36cfd69-1466-41a5-9aec-2a9b26d37811-00%40eu-central-1.amazonses.com.

Re: [Django] #32210: Django Admin with Inlines not using UUIDField default value

[Django]

#32210: Django Admin with Inlines not using UUIDField default value
--+
 Reporter:  Joseph Metzinger  |Owner:  Neeraj Kumar
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  3.1
 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 Neeraj Kumar):

 * cc: Neeraj Kumar (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070182c72641cd-b99893b1-c569-4bac-afb4-8fffccb92b92-00%40eu-central-1.amazonses.com.

Re: [Django] #32210: Django Admin with Inlines not using UUIDField default value

[Django]

#32210: Django Admin with Inlines not using UUIDField default value
--+
 Reporter:  Joseph Metzinger  |Owner:  Neeraj Kumar
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by David Wobrock):

 * cc: David Wobrock (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  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/01070182c75ba078-65d227a2-e437-4f9e-b068-27797b9a242d-00%40eu-central-1.amazonses.com.

Re: [Django] #33927: Rendering a read-only ArrayField with choices crashes.

[Django]

#33927: Rendering a read-only ArrayField with choices crashes.
---+-
 Reporter:  David Svenson  |Owner:  David Wobrock
 Type:  Bug|   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 David Wobrock):

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


Comment:

 [https://github.com/django/django/pull/15984 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/01070182c77be102-3e6df5d6-d851-4706-bde0-e38bf953e814-00%40eu-central-1.amazonses.com.

[Django] #33947: Adding db_index to a field inherited from an Abstract class does not propagate the change to the models subclassing it

[Django]

#33947: Adding db_index to a field inherited from an Abstract class does not
propagate the change to the models subclassing it
-+-
   Reporter:  awiebe |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  3.2
  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 have a bunch of Models of the form
 {{{
 #!div style="font-size: 80%"
   {{{#!python
   class AbstractOwnershipModel(models.Model):
  owner_user= models.ForeignKey('auth.User')
  class Meta:
   abstract = True
   }}}
 }}}

 Which I tried to change to
 {{{
 #!div style="font-size: 80%"
   {{{#!python
   class AbstractOwnershipModel(models.Model):
  owner_user= models.ForeignKey('auth.User',db_index=True)
  class Meta:
   abstract = True
   }}}
 }}}

 But makemigrations reports that there are no changes even though I would
 expect a bunch of indexes to be created.

-- 
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/01070182c7b73a52-a3a94ca4-a37c-4efe-8fec-e33430de4996-00%40eu-central-1.amazonses.com.

Re: [Django] #33947: Adding db_index to a field inherited from an Abstract class does not propagate the change to the models subclassing it

[Django]

#33947: Adding db_index to a field inherited from an Abstract class does not
propagate the change to the models subclassing it
-+-
 Reporter:  awiebe   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  3.2
  (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 awiebe:

Old description:

> I have a bunch of Models of the form
> {{{
> #!div style="font-size: 80%"
>   {{{#!python
>   class AbstractOwnershipModel(models.Model):
>  owner_user= models.ForeignKey('auth.User')
>  class Meta:
>   abstract = True
>   }}}
> }}}
>
> Which I tried to change to
> {{{
> #!div style="font-size: 80%"
>   {{{#!python
>   class AbstractOwnershipModel(models.Model):
>  owner_user= models.ForeignKey('auth.User',db_index=True)
>  class Meta:
>   abstract = True
>   }}}
> }}}
>
> But makemigrations reports that there are no changes even though I would
> expect a bunch of indexes to be created.

New description:

 I have a bunch of Models of the form
 {{{
 #!div style="font-size: 80%"
   {{{#!python
   class AbstractOwnershipModel(models.Model):
  owner_user= models.ForeignKey('auth.User')
  class Meta:
   abstract = True
  class AnOwnedModel(AbstractOwnershipModel):
#...
   }}}
 }}}

 Which I tried to change to
 {{{
 #!div style="font-size: 80%"
   {{{#!python
   class AbstractOwnershipModel(models.Model):
  owner_user= models.ForeignKey('auth.User',db_index=True)
  class Meta:
   abstract = True
   }}}
 }}}

 But makemigrations reports that there are no changes even though I would
 expect a bunch of indexes to be created.

--

-- 
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/01070182c7ba4c86-9fb8a2c6-292e-4fa6-8a9e-e8a3d4ce6a6f-00%40eu-central-1.amazonses.com.

Re: [Django] #21204: Query.defer() failure - deferred columns calculated per table instead per alias

[Django]

#21204: Query.defer() failure - deferred columns calculated per table instead 
per
alias
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Simon
 |  Charette
 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 Simon Charette):

 * owner:  (none) => Simon Charette
 * needs_better_patch:  1 => 0
 * 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/01070182c8003ed8-4183e0fe-226c-4b6f-81e0-ec4fccf487b8-00%40eu-central-1.amazonses.com.

Re: [Django] #21682: Use app_config as a reference instead of app_label in Options (Model._meta)

[Django]

#21682: Use app_config as a reference instead of app_label in Options 
(Model._meta)
-+-
 Reporter:  Aymeric Augustin |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  app-loading  | 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 => closed
 * resolution:   => wontfix


Comment:

 Finally going to resolve this ticket as ''wontfix''. As pointed out by
 Aymeric there are complications wrt/ to migration fake models and quite
 frankly it's not clear to me what benefits it would provide over the rare
 cases where `self.apps(self.app_label)` is used.

-- 
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/01070182c89b95fe-91d98fff-7a17-457a-ac0c-d5032ae790f0-00%40eu-central-1.amazonses.com.

Re: [Django] #22158: Allow model level custom lookups

[Django]

#22158: Allow model level custom lookups
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 With the approach we've taken with `RegisterLookupMixin` this could be
 implemented by

 1. Having `models.Model` extend `RegisterLookupMixin`
 2. Adding a `lookup` decorator as described above that wraps the decorated
 function in something that has a `contribute_to_class` method. This method
 would then call `model.register_lookup` with a lookup factory.
 3. Adjusting `sql.Query.build_lookup` to consider `self.model.get_lookup`
 and call into the wrapped function with `rhs`

 e.g. the object that could be registered as a model lookup would be
 something like

 {{{#!python
 class ModelLookupFactory:
def __init__(self, method):
self.model = None
self.method = method

def contribute_to_class(self, cls, name, private_only=False):
self.model = cls
cls.register_lookup(self, name)

def __call__(self, rhs):
# XXX: Use introspection on self.method to avoid passing rhs
# if the arity of self.method is 1. Ensure isinstance(rhs, bool)
# and negate if necessary
return lookups.Exact(self.method(self.model, rhs), True)

 lookup = ModelLookupFactory
 }}}

-- 
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/01070182c8b9f136-5fe67546-f3f5-443e-886e-e9af62a85528-00%40eu-central-1.amazonses.com.

Re: [Django] #22757: prefetch_related isn't as effecient as it could be with GenericForeignKey and proxy models

[Django]

#22757: prefetch_related isn't as effecient as it could be with 
GenericForeignKey
and proxy models
-+-
 Reporter:  gwahl@…  |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | 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):

 * owner:  Paulo => (none)
 * status:  assigned => new


Comment:

 This is achievable by grouping queries by concrete model in
 `GenericForeignKey.get_prefetch_queryset` but will also likely require
 adjusting the prefetching logic to allow for some custom logic to be run
 on assignment so returned `Child` instances can be turned into
 `ProxiedChild`.

-- 
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/01070182c8d82beb-5be781d7-2c30-4f29-9ecf-4b351f42b3da-00%40eu-central-1.amazonses.com.

Re: [Django] #24272: Better error messages for prefetch_related

[Django]

#24272: Better error messages for prefetch_related
-+-
 Reporter:  Todor Velichkov  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  GenericRelation,   |
  related_query_name |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 I think that we can actually close this one as a duplicate of #33651 as
 the latter would allow the following syntax to be used

 {{{#!python
 TaggedItem.objects.prefetch_related(
 GenericPrefetch(
 "content_object", [
 Book.objects.select_related('author'),
 Movie.objects.select_related('director'),
 ]
 ),
 )
 }}}

-- 
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/01070182c8e36490-5ea5c464-fa09-4863-ba8c-f9d581e4f703-00%40eu-central-1.amazonses.com.

Re: [Django] #33651: Support prefetch GenericForeignKey with custom queryset.

[Django]

#33651: Support prefetch GenericForeignKey with custom queryset.
-+-
 Reporter:  elonzh   |Owner:
 |  Gullapalli Saisurya Revanth
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  4.0
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  GenericForeignKey| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 #24272 was a duplicate. One thing I noticed while reviewing it is that the
 signature of `GenericPrefetch` would likely be ergonomic as
 `GenericPrefetch(relation: str, querysets: list[QuerySet])` instead of
 `querysets: dict[Model, QuerySet]` since the model can be inferred from
 `queryset.model` anyway.

-- 
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/01070182c8e6000d-9ccf8197-6bd5-45b6-92e1-7c693208bec5-00%40eu-central-1.amazonses.com.

Re: [Django] #33947: Adding db_index to a field inherited from an Abstract class does not propagate the change to the models subclassing it

[Django]

#33947: Adding db_index to a field inherited from an Abstract class does not
propagate the change to the models subclassing it
-+-
 Reporter:  awiebe   |Owner:  nobody
 Type:  Uncategorized|   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
-+-
Changes (by Alex Morega):

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


Comment:

 >But makemigrations reports that there are no changes even though I would
 expect a bunch of indexes to be created.

 That's because the index is
 
[https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.ForeignKey
 already created by default]:

 >A database index is automatically created on the `ForeignKey`. You can
 disable this by setting `db_index` to `False`. You may want to avoid the
 overhead of an index if you are creating a foreign key for consistency
 rather than joins, or if you will be creating an alternative index like a
 partial or multiple column index.

 You can check by connecting to the database using `./manage.py dbshell`
 and looking at the database schema.

-- 
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/01070182c92d83e3-6563c2bb-0046-4b28-b3f4-f97d474d119a-00%40eu-central-1.amazonses.com.

Re: [Django] #33651: Support prefetch GenericForeignKey with custom queryset.

[Django]

#33651: Support prefetch GenericForeignKey with custom queryset.
-+-
 Reporter:  elonzh   |Owner:
 |  Gullapalli Saisurya Revanth
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  4.0
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  GenericForeignKey| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Todor Velichkov):

 * cc: Todor Velichkov (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070182c94c5bf7-52148d40-2f8a-4d1a-9fe6-a7a9a10831ea-00%40eu-central-1.amazonses.com.