[Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
   Reporter:  selcuk |  Owner:  nobody
   Type:  Bug| Status:  new
  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  |
-+-
 Consider the following models:

 {{{
 class Pet(models.Model):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 name = models.CharField(max_length=20)


 class Toy(models.Model):
 pet = models.ForeignKey(Pet, models.CASCADE, related_name="toys")
 name = models.CharField(max_length=20)
 }}}
 The following works and caches the deferred {{{pet}}} instance as
 expected:
 {{{
 pet = Pet.objects.create(name="Fifi")
 toy_bone = Toy(pet_id=str(pet.id), name="Bone")
 print(toy_bone.pet)
 }}}
 It fails if {{{prefetch_related_objects}}} is used:
 {{{
 pet = Pet.objects.create(name="Fifi")
 toy_bone = Toy(pet_id=str(pet.id), name="Bone")
 prefetch_related_objects([toy_bone], "pet")
 print(toy_bone.pet)
 }}}
 {{{
 raise self.RelatedObjectDoesNotExist(
 ^
 prefetch_related.models.Toy.pet.RelatedObjectDoesNotExist: Toy has no pet.
 }}}
 The behaviour is inconsistent as str to UUID conversion is automatically
 performed in the first example.

 One may argue that the use of {{{prefetch_related_objects}}} is redundant
 in this case. However, it is useful in async code where deferred lookups
 are not automatic.
-- 
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/0107018f4827043d-c5479418-16e7-4c3e-9062-dbd59ce74af3-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  selcuk   |Owner:  nobody
 Type:  Bug  |   Status:  new
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 selcuk:

Old description:

> Consider the following models:
>
> {{{
> class Pet(models.Model):
> id = models.UUIDField(primary_key=True, default=uuid.uuid4,
> editable=False)
> name = models.CharField(max_length=20)
>

> class Toy(models.Model):
> pet = models.ForeignKey(Pet, models.CASCADE, related_name="toys")
> name = models.CharField(max_length=20)
> }}}
> The following works and caches the deferred {{{pet}}} instance as
> expected:
> {{{
> pet = Pet.objects.create(name="Fifi")
> toy_bone = Toy(pet_id=str(pet.id), name="Bone")
> print(toy_bone.pet)
> }}}
> It fails if {{{prefetch_related_objects}}} is used:
> {{{
> pet = Pet.objects.create(name="Fifi")
> toy_bone = Toy(pet_id=str(pet.id), name="Bone")
> prefetch_related_objects([toy_bone], "pet")
> print(toy_bone.pet)
> }}}
> {{{
> raise self.RelatedObjectDoesNotExist(
> ^
> prefetch_related.models.Toy.pet.RelatedObjectDoesNotExist: Toy has no
> pet.
> }}}
> The behaviour is inconsistent as str to UUID conversion is automatically
> performed in the first example.
>
> One may argue that the use of {{{prefetch_related_objects}}} is redundant
> in this case. However, it is useful in async code where deferred lookups
> are not automatic.

New description:

 Consider the following models:

 {{{
 class Pet(models.Model):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 name = models.CharField(max_length=20)


 class Toy(models.Model):
 pet = models.ForeignKey(Pet, models.CASCADE, related_name="toys")
 name = models.CharField(max_length=20)
 }}}
 The following works and caches the deferred {{{pet}}} instance as
 expected:
 {{{
 pet = Pet.objects.create(name="Fifi")
 toy_bone = Toy(pet_id=str(pet.id), name="Bone")
 print(toy_bone.pet)
 }}}
 It fails if {{{prefetch_related_objects}}} is used:
 {{{
 pet = Pet.objects.create(name="Fifi")
 toy_bone = Toy(pet_id=str(pet.id), name="Bone")
 prefetch_related_objects([toy_bone], "pet")
 print(toy_bone.pet)
 }}}
 {{{
 raise self.RelatedObjectDoesNotExist(
 ^
 prefetch_related.models.Toy.pet.RelatedObjectDoesNotExist: Toy has no pet.
 }}}
 The behaviour is inconsistent as str to UUID conversion is automatically
 performed in the first example.

 One may argue that the use of {{{prefetch_related_objects}}} is redundant
 in this case. However, it is useful in async code where deferred lookups
 are not automatic.

 Unit test to reproduce the issue:
 https://github.com/django/django/pull/18132

--
-- 
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/0107018f482a877f-361d5190-fa3d-493a-b85a-ffeda76a4fa2-00%40eu-central-1.amazonses.com.

Re: [Django] #35433: NumberInput off-by-one on min value for type range

[Django]

#35433: NumberInput off-by-one on min value for type range
-+--
 Reporter:  mitch99  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by Sarah Boyce):

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

Comment:

 This is missing information to determine whether this is a bug or not, I
 need to see the how the form is defined and how the field weight is
 defined on the model.
-- 
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/0107018f484548ca-0a7d003d-1922-4270-b5ef-0144c2a7fd1d-00%40eu-central-1.amazonses.com.

Re: [Django] #35429: Add argparse choices to --database options

[Django]

#35429: Add argparse choices to --database options
-+-
 Reporter:  Adam Johnson |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
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:  0
Easy pickings:  1|UI/UX:  0
-+-
Comment (by Mariusz Felisiak):

 Replying to [ticket:35429 Adam Johnson]:
 > We can add [https://docs.python.org/3.12/library/argparse.html#choices
 argparse’s choices] for validation:
 >
 > {{{
 > --- django/core/management/commands/migrate.py
 > +++ django/core/management/commands/migrate.py
 > @@ -47,6 +47,7 @@ def add_arguments(self, parser):
 >  parser.add_argument(
 >  "--database",
 >  default=DEFAULT_DB_ALIAS,
 > +choices=tuple(connections),
 >  help=(
 >  'Nominates a database to synchronize. Defaults to the
 "default" '
 >  "database."
 > }}}


 Can we? Do we really want to iterate over connections? As far as I'm
 aware, this will force initialization of all database connections. I don't
 think it's acceptable. IMO it's not worth doing.
-- 
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/0107018f48834ec4-eca911e9-b63b-4954-9d69-f453e4b9aa48-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  nobody
 Type:  Bug  |   Status:  new
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 Selcuk Ayguney:

Old description:

> Consider the following models:
>
> {{{
> class Pet(models.Model):
> id = models.UUIDField(primary_key=True, default=uuid.uuid4,
> editable=False)
> name = models.CharField(max_length=20)
>

> class Toy(models.Model):
> pet = models.ForeignKey(Pet, models.CASCADE, related_name="toys")
> name = models.CharField(max_length=20)
> }}}
> The following works and caches the deferred {{{pet}}} instance as
> expected:
> {{{
> pet = Pet.objects.create(name="Fifi")
> toy_bone = Toy(pet_id=str(pet.id), name="Bone")
> print(toy_bone.pet)
> }}}
> It fails if {{{prefetch_related_objects}}} is used:
> {{{
> pet = Pet.objects.create(name="Fifi")
> toy_bone = Toy(pet_id=str(pet.id), name="Bone")
> prefetch_related_objects([toy_bone], "pet")
> print(toy_bone.pet)
> }}}
> {{{
> raise self.RelatedObjectDoesNotExist(
> ^
> prefetch_related.models.Toy.pet.RelatedObjectDoesNotExist: Toy has no
> pet.
> }}}
> The behaviour is inconsistent as str to UUID conversion is automatically
> performed in the first example.
>
> One may argue that the use of {{{prefetch_related_objects}}} is redundant
> in this case. However, it is useful in async code where deferred lookups
> are not automatic.
>
> Unit test to reproduce the issue:
> https://github.com/django/django/pull/18132

New description:

 Consider the following models:

 {{{
 class Pet(models.Model):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 name = models.CharField(max_length=20)


 class Toy(models.Model):
 pet = models.ForeignKey(Pet, models.CASCADE, related_name="toys")
 name = models.CharField(max_length=20)
 }}}
 The following works and caches the deferred {{{pet}}} instance as
 expected:
 {{{
 pet = Pet.objects.create(name="Fifi")
 toy_bone = Toy(pet_id=str(pet.id), name="Bone")
 print(toy_bone.pet)
 }}}
 It fails if {{{prefetch_related_objects}}} is used:
 {{{
 pet = Pet.objects.create(name="Fifi")
 toy_bone = Toy(pet_id=str(pet.id), name="Bone")
 prefetch_related_objects([toy_bone], "pet")
 print(toy_bone.pet)
 }}}
 {{{
 raise self.RelatedObjectDoesNotExist(
 ^
 prefetch_related.models.Toy.pet.RelatedObjectDoesNotExist: Toy has no pet.
 }}}
 The behaviour is inconsistent as str to UUID conversion is automatically
 performed in the first example.

 One may argue that the use of {{{prefetch_related_objects}}} is redundant
 in this case. However, it is useful in async code where deferred lookups
 are not automatic.

 Unit test to reproduce the issue and the suggested fix:
 https://github.com/django/django/pull/18132

--
-- 
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/0107018f4892e9c1-9c883fdf-c0b3-421d-bf88-d7da3b2213e1-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  nobody
 Type:  Bug  |   Status:  new
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
-+-
Changes (by Selcuk Ayguney):

 * has_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/0107018f48947a0b-e2ecbf4c-5a9c-41fa-b821-c6c445e19cf6-00%40eu-central-1.amazonses.com.

Re: [Django] #35431: Failing to serialize NumericRange with CheckConstraint on IntegerRangeField

[Django]

#35431: Failing to serialize NumericRange with CheckConstraint on 
IntegerRangeField
+--
 Reporter:  Arran   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  5.0
 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 Mariusz Felisiak):

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

Comment:

 You need to add `django.contrib.postgres` to the `INSTALLED_APPS` this
 will register PostgreSQL-specific serializers.
-- 
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/0107018f49304fe9-8a5e722f-00f1-4b21-918f-d2f680f313ed-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  Selcuk
 |  Ayguney
 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 Jacob Walls):

 * owner:  nobody => Selcuk Ayguney
 * stage:  Unreviewed => Accepted
 * status:  new => assigned

Comment:

 I ran into a symptom of this problem recently and didn't get far enough to
 diagnose the root cause.

 I was prefetching at two levels, so my
 
[https://github.com/archesproject/arches/blob/3940c46627fb3dedbbe58cb64f892b517d86dc99/arches/app/utils/index_database.py#L220-L224
 hack] was to just iterate the objects and reselect the object at the
 intermediate level (reintroducing N+1 queries at that level), but at least
 allowing me to avoid N+1 queries at the second level.

 Thanks for the report.
-- 
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/0107018f496d0031-35b6f9be-e94f-4afa-8443-9e673817fbc6-00%40eu-central-1.amazonses.com.

Re: [Django] #35425: .save(force_update=True) not respected for model instances with default primary keys

[Django]

#35425: .save(force_update=True) not respected for model instances with default
primary keys
-+-
 Reporter:  Jacob Walls  |Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (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):

 * cc: Simon Charette (added)
 * stage:  Unreviewed => Accepted

Comment:

 Having `save()` always do the expected thing when called on a newly
 created instance of a model with a primary key configured with a Python
 level default is a complex situation as you've pointed out.

 Given the ORM has historically expected newly created model instances to
 be used for ''additions'' and uses `_state.adding` to take a decision in
 the face of ambiguity I still believe that #29260 was the right thing to
 do.

 With that being said, when being explicitly told what to do via
 `force_update=True` there is no `save` ambiguity and thus we should not
 fallback to `force_insert`. In this sense I think this represents a valid
 bug and the provided patch seems adequate.
-- 
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/0107018f49798057-7e4448ea-8c0b-49b2-9e45-8190908de160-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  Selcuk
 |  Ayguney
 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):

 * cc: Simon Charette (added)

Comment:

 Have we performed any form of benchmarks to assess the impact of calling
 `to_python` for each sides of the prefetching ''bridge''?
 `Field.to_python` can perform non-trivial validation and instance checks
 that quickly add up when dealing with large collection of objects.

 Given `prefetch_related_object` is normally called from a
 `prefetch_related` queryset where both sides are already guaranteed to be
 of the right type and serializers/forms are meant to be turn
 representations of objects to the expected field types at input boundaries
 it seems like this change could do more harm than good both from a
 performance and areas of concerns violation perspective.

 My question to you would be why you are assigning the unexpected type to
 field in the first place (the `pet_id=str(pet.id)`)? Plenty of things
 subtly break if you assign the string representation of a `DateField`,
 `DecimalField`, `FloatField`, etc to a model instance field instead of the
 proper type so I'm not sure how this particular case is special. If you
 have to assign such properties I believe you should call `.full_clean()` /
 `clean_fields()` on the model instance and be ready to deal with any
 associated `ValidationError`.

 I'm more of the opinion that we should wont-fix this issue than proceed
 here.
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f499d80c7-8e25c675-3400-4c02-abe6-0f7198d44b1c-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  Selcuk
 |  Ayguney
 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
-+-
Comment (by Selcuk Ayguney):

 True, I already implemented a similar workaround in the codebase I was
 working on when I spotted this issue, and honestly I'm not sure if this is
 a wontfix or a legitimate bug. I haven't performed any benchmark either.
 My rationale was that the usual Django deferred lookup works when a
 {{{str}}} is used, but it only fails when {{{prefetch_related_objects}}}
 is used, so this looked like the more consistent behaviour. I don't think
 other types such as {{{DecimalField}}} etc are commonly used as primary
 keys.

 In my real world example the model instance is instantiated from a JSON
 object in a generic way, and foreign keys are set using the {{{attname}}}s
 where it is not possible to know the actual data type.
-- 
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/0107018f49a95e9e-a8707c92-adab-42eb-91b0-7fcd3bcecf65-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  Selcuk
 |  Ayguney
 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
-+-
Comment (by Simon Charette):

 > My rationale was that the usual Django deferred lookup works when a str
 is used, but it only fails when prefetch_related_objects is used, so this
 looked like the more consistent behaviour.

 I understand where that could be perceived as inconsistent but I would
 argue that it's undefined behaviour in both cases. It only happens to work
 in the lazy loading case because it incurs a query that defers the lookup
 to the backend.

 > I don't think other types such as DecimalField etc are commonly used as
 primary keys.

 Fair point, it remains unnecessary while arguably faster validation for
 `AutoField, `UUIDField`, and others though.

 > In my real world example the model instance is instantiated from a JSON
 object in a generic way, and foreign keys are set using the attnames where
 it is not possible to know the actual data type.

 If you are turning a ''raw'' JSON object to a model instance I think that
 you should be expected to call `clean_fields` at the very least.
-- 
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/0107018f49ae520c-f98c53bf-6096-4414-b673-78b1bfffca5e-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  Selcuk
 |  Ayguney
 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
-+-
Comment (by Selcuk Ayguney):

 > It only happens to work in the lazy loading case because it incurs a
 query that defers the lookup to the backend.

 Agreed. Granted, it is still because of the database backend, but strings
 can be used interchangeably with UUIDs in almost everywhere, for example
 {{{Toy.objects.filter(pk="-...").exists()}}}. This makes the
 behaviour in this ticket even more peculiar.

 > That's what serialization layers are usually for; turn data into their
 proper model equivalent.

 Sure thing. As I mentioned I have already changed my code to validate the
 instance, but this behaviour took me by surprise and it looked like it
 violates the least astonishment principle.
-- 
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/0107018f49b8dc5b-d0705c62-fab6-46e9-aef4-0e06e9b62962-00%40eu-central-1.amazonses.com.

Re: [Django] #35306: Improve documentation for the various date format settings

[Django]

#35306: Improve documentation for the various date format settings
-+-
 Reporter:  Richard  |Owner:  Lufafa
 Type:   |  Joshua
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  5.0
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  LANGUAGE_CODE,   | Triage Stage:  Accepted
  DATE_FORMAT|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * 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/0107018f49cb07ff-513963e0-acc3-42ec-80db-66afe3078080-00%40eu-central-1.amazonses.com.

Re: [Django] #35381: Regression on json null value constraints in django 4.2

[Django]

#35381: Regression on json null value constraints in django 4.2
-+-
 Reporter:  Olivier Tabone   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.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
-+-
Comment (by Simon Charette):

 I've looked into it as well and #35167 only provides a partial solution
 here IMO as it would require the `Q.check` logic to also pass around
 `for_save` to activate the code path it introduces.

 I'm starting to believe that in order to finally solve this null ambiguity
 problem we should

 1. Introduce a `JSONNull` expression to disambigutate between the two. It
 would also allow the creation of model instances with a JSON `null` which
 is convoluated today as it requires `models.Value(None,
 models.JSONField())` to be used.
 2. Deprecate `filter(jsonfield=None)` meaning JSON `null` by requiring
 `JSONNull` to be used instead. Should we only do this at the top level to
 still allow `jsonfield__key=None` to filter against `null` keys? An
 alternative would be to introduce a `__jsonnull` lookup.

 The ''good news'' is that Django makes it very hard to store JSON null in
 the first place since #34754 so this kind of constraints should be rarely
 needed.
-- 
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/0107018f49d2ed8b-ddc5d54d-50c8-4731-b95e-0c5c322d40f1-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  Selcuk
 |  Ayguney
 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
-+-
Comment (by Jacob Walls):

 > I understand where that could be perceived as inconsistent but I would
 argue that it's undefined behaviour in both cases. It only happens to work
 in the lazy loading case because it incurs a query that defers the lookup
 to the backend.

 Interesting. If `pet_id=str(pet.id)` is undefined, then I'm looking at a
 huge yak shave to audit my projects for UUIDs represented as strings,
 which I'm pretty sure we're doing in every view, test, model, migration...
-- 
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/0107018f49dd59d7-9963bae5-c75c-4ec7-b934-d9fedaa8b275-00%40eu-central-1.amazonses.com.

Re: [Django] #34917: Links in the Django admin should be underlined.

[Django]

#34917: Links in the Django admin should be underlined.
-+-
 Reporter:  Dmitriy Chukhin  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  anchor |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Sarah Boyce):

 * 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/0107018f49de083c-9062cde3-b8f1-491d-a4d8-80a4d874c710-00%40eu-central-1.amazonses.com.

Re: [Django] #32770: Add system check for django.contrib.postgres in INSTALLED_APPS when using OpClass().

[Django]

#32770: Add system check for django.contrib.postgres in INSTALLED_APPS when 
using
OpClass().
-+-
 Reporter:  Seth Yastrov |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 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 Simon Charette):

 * cc: Simon Charette (added)

Comment:

 In the light of continuous reports of users running into this qwirk
 (#35431 being the latest one) I wonder if we could

 1. Have all fields defined in `contrib.postgres` have their `check` method
 make sure that `'django.contrib.postgres' in INSTALLED_APPS`
 2. Adjust `Model._check_indexes` to do something similar to what we did
 with `Constraint` check delegation in
 0fb104dda287431f5ab74532e45e8471e22b58c8
 3. Have both `contrib.postgres` indexes and constraints perform the same
 `'django.contrib.postgres' in INSTALLED_APPS` check

 Thoughts?
-- 
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/0107018f49e285df-aa009afb-9715-4cfb-a0cd-d9217bfd8b81-00%40eu-central-1.amazonses.com.

Re: [Django] #34917: Links in the Django admin should be underlined.

[Django]

#34917: Links in the Django admin should be underlined.
-+-
 Reporter:  Dmitriy Chukhin  |Owner:  Maira
 Type:   |  Usman
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  anchor |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Sarah Boyce):

 * owner:  nobody => Maira Usman
 * 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/0107018f49e4fe7c-5b51e20f-3bd7-4530-8d64-c45d0789a456-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  Selcuk
 |  Ayguney
 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
-+-
Comment (by Simon Charette):

 There's a difference between lookup against the database (e.g.
 `filter(pet_id=str(pet.id))`) which performs implicit conversions and
 direct model attribute assignments. I would argue that if you explicitly
 assign the string representation of objects meant to be stored in a field
 to a model instance you are effectively doing things wrong.
-- 
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/0107018f49e5be80-e56e1091-ac0b-4ae0-8964-0b67c2f89cb7-00%40eu-central-1.amazonses.com.

Re: [Django] #35429: Add argparse choices to --database options

[Django]

#35429: Add argparse choices to --database options
-+-
 Reporter:  Adam Johnson |Owner:  Jae Hyuck
 Type:   |  Sa
  Cleanup/optimization   |   Status:  assigned
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:  0
Easy pickings:  1|UI/UX:  0
-+-
Comment (by Simon Charette):

 > Do we really want to iterate over connections? As far as I'm aware, this
 will force initialization of all database connections

 I know it's confusing (I had to check myself to make sure when accepting
 the ticket) but `connections.__iter__`
 
[https://github.com/django/django/blob/9a27c76021f934201cccf12215514a3091325ec8/django/utils/connection.py#L72-L73
 doesn't create any connections] it simply iterates over
 `settings.DATABASES`.
-- 
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/0107018f49f13ff5-622f40bd-9897-4063-b4cf-caa92f51ae8c-00%40eu-central-1.amazonses.com.

Re: [Django] #35433: NumberInput off-by-one on min value for type range

[Django]

#35433: NumberInput off-by-one on min value for type range
-+--
 Reporter:  mitch99  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Comment (by mitch99):

 Please see below:

 {{{
 class ContentProfileDefinitionForm(forms.ModelForm):
 class Meta:
 model = ContentProfileDefinition
 fields = ["other", "weight"]
 widgets = {
 "weight": forms.NumberInput(
 attrs={
 "type": "range",
 "step": "1",
 "min": "1",
 "max": "5",
 }
 ),
 }
 }}}


 {{{
 class ContentProfileDefinition(models.Model):
 other = models.ForeignKey("Other", on_delete=models.CASCADE)
 weight = models.PositiveSmallIntegerField(
 default=1,
 help_text="Weight",
 validators=[
 MinValueValidator(1),
 MaxValueValidator(5),
 ],
 )
 }}}
-- 
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/0107018f4a23a0eb-be623786-10e2-400e-9236-6aaf984899f1-00%40eu-central-1.amazonses.com.

[Django] #35435: NumberInput off-by-one on min value for type range

[Django]

#35435: NumberInput off-by-one on min value for type range
-+
   Reporter:  mitch99|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Forms  |Version:  5.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 Follow-up to #35433 which was closed (and I couldn't reopen):

 {{{
 class ContentProfileDefinitionForm(forms.ModelForm):
 class Meta:
 model = ContentProfileDefinition
 fields = ["other", "weight"]
 widgets = {
 "weight": forms.NumberInput(
 attrs={
 "type": "range",
 "step": "1",
 "min": "1",
 "max": "5",
 }
 ),
 }

 class ContentProfileDefinition(models.Model):
 other = models.ForeignKey("Other", on_delete=models.CASCADE)
 weight = models.PositiveSmallIntegerField(
 default=1,
 help_text="Weight",
 validators=[
 MinValueValidator(1),
 MaxValueValidator(5),
 ],
 )

 }}}

 I expect the min value on the range input to be 1, but it's actually 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/0107018f4a287874-2dff6d17-e14e-45dc-9dc7-a947afef797b-00%40eu-central-1.amazonses.com.

Re: [Django] #35433: NumberInput off-by-one on min value for type range

[Django]

#35433: NumberInput off-by-one on min value for type range
-+--
 Reporter:  mitch99  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by mitch99):

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

Comment:

 Unable to reopen so recreated at #35435
-- 
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/0107018f4a28eb81-53dc1c29-c809-487a-ae09-e9b0726ec8c5-00%40eu-central-1.amazonses.com.

Re: [Django] #35435: NumberInput off-by-one on min value for type range

[Django]

#35435: NumberInput off-by-one on min value for type range
---+--
 Reporter:  mitch99|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Forms  |  Version:  5.0
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by mitch99):

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

-- 
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/0107018f4a297cf9-4b20d926-15a3-4984-a5af-e8468a2f495d-00%40eu-central-1.amazonses.com.

Re: [Django] #35433: NumberInput off-by-one on min value for type range

[Django]

#35433: NumberInput off-by-one on min value for type range
-+--
 Reporter:  mitch99  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Comment (by mitch99):

 Strangely it's not an off-by-one. It seems the min value is ignored and
 always set to 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/0107018f4a388f26-2a2b7aa6-8280-45ed-a096-626bcbce396c-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 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 Jacob Walls):

 * component:  Database layer (models, ORM) => Documentation
 * has_patch:  1 => 0
 * owner:  Selcuk Ayguney => (none)
 * stage:  Accepted => Unreviewed
 * status:  assigned => new
 * type:  Bug => Cleanup/optimization

Comment:

 Thanks, that helps me understand the severity of the anti-pattern.

 Now I'm aware that despite the implicit type-conversion you get on the
 database-side, python-side operations like `==` or `obj in queryset`
 become unsafe when a stringified UUID is assigned to a model attribute.

 Or even  `queryset.contains()`, but only if called on an evaluated
 queryset.


 {{{
 In [1]: from models import GraphModel

 In [2]: original = GraphModel.objects.first()

 In [3]: unsafe = GraphModel(str(original.pk))

 In [4]: all_graphs = GraphModel.objects.all()

 In [5]: all_graphs.contains(unsafe)
 Out[5]: True

 In [6]: len(all_graphs)
 Out[6]: 1

 In [7]: all_graphs.contains(unsafe)
 Out[7]: False

 }}}

 I think a version of that REPL would be useful in the docs somewhere.
 Calling your query tested by testing as far as line 5 but not line 7 is
 something I can see happening.

 Selcuk, is it okay if I reframe your ticket as a documentation request and
 ask for another opinion?
-- 
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/0107018f4afe98e9-93e3c21d-091f-458f-8877-1c0f2fc36662-00%40eu-central-1.amazonses.com.

Re: [Django] #35424: Migration autodetector fails when order_with_respect_to is removed, but an _order field remains

[Django]

#35424: Migration autodetector fails when order_with_respect_to is removed, but 
an
_order field remains
+--
 Reporter:  Stuart Attenborrow  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  4.2
 Severity:  Normal  |   Resolution:  needsinfo
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Comment (by Stuart Attenborrow):

 Thanks for looking into it. Due to the error you're seeing, the migrations
 had to be staggered to achieve the changes. e.g.:

 - [https://github.com/stuarta0/django-order-with-respect-
 to/blob/main/mysite/polls/migrations/0002_alter_choice_order_with_respect_to.py
 0002_alter_choice_order_with_respect_to]: arranging the test.
 - [https://github.com/stuarta0/django-order-with-respect-
 to/blob/main/mysite/polls/migrations/0003_choice_order.py
 0003_choice_order]: we wanted to move to our own ordering, but retain the
 data from the existing hidden field. Removing order_with_respect_to
 would've lost the data, so we added a placeholder field to store the
 result, and copied the values across with a simple python migration.
 - [https://github.com/stuarta0/django-order-with-respect-
 to/blob/main/mysite/polls/migrations/0004_alter_choice_options_and_more.py
 0004_alter_choice_options_and_more]: the order_with_respect_to field can
 be removed, which drops the hidden column.
 - [https://github.com/stuarta0/django-order-with-respect-
 
to/blob/main/mysite/polls/migrations/0005_alter_choice_options_rename_order_choice__order.py
 0005_alter_choice_options_rename_order_choice__order]: finally, we can
 rename our placeholder field.

 Since the code is 8 years old and written by another author, I can't give
 you an explicit reason why the "_order" name was reused other than my
 assumption that "order" is a reserved word and "_order" was good enough
 for django internals at the time. However, it hasn't been an issue because
 django never had code that was structured in the way it is now.

 The answer for new projects is probably to remake or squash migrations to
 avoid it, but it's quite difficult on a legacy project with this scale of
 migrations. My suggested change in the original report fixes the issue for
 this case, but I haven't run django tests to see if it fails in other
 cases.
-- 
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/0107018f4b411483-93edd662-e371-4083-8f94-b66ef89e4b47-00%40eu-central-1.amazonses.com.

Re: [Django] #35433: NumberInput min_value attr overridden by IntegerField.widget_attrs (was: NumberInput off-by-one on min value for type range)

[Django]

#35433: NumberInput min_value attr overridden by IntegerField.widget_attrs
-+--
 Reporter:  mitch99  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Tim Graham):

 * easy:  1 => 0
 * summary:  NumberInput off-by-one on min value for type range =>
 NumberInput min_value attr overridden by IntegerField.widget_attrs

Comment:

 The root cause is that `Field.__init__()`
 
[https://github.com/django/django/blob/9a27c76021f934201cccf12215514a3091325ec8/django/forms/fields.py#L158-L160
 overrides a widget's attrs] with `Field.widget_attrs` which includes
 `min_value=0` from
 
[https://github.com/django/django/blob/9a27c76021f934201cccf12215514a3091325ec8/django/db/models/fields/__init__.py#L2401
 PositiveIntegerField.formfield()].

 I'm not sure if we should change the behavior. The most appropriate fix
 for your use case might be to subclass `PositiveIntegerField` and override
 `formfield()` to set `min_value=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/0107018f4bb98df8-272cf77b-df73-46cb-972d-962c251b399f-00%40eu-central-1.amazonses.com.

Re: [Django] #35433: NumberInput min_value attr overridden by IntegerField.widget_attrs

[Django]

#35433: NumberInput min_value attr overridden by IntegerField.widget_attrs
-+--
 Reporter:  mitch99  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Comment (by David Sanders):

 Yup what Tim said: There will be people relying on this existing behaviour
 👍

 Another way to get `min="1"` is to use django-widget-tweaks:
 https://github.com/jazzband/django-widget-tweaks  I just tested it out and
 it works 👍
-- 
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/0107018f4bc04105-d2c78c44-3c55-4888-9921-28cd6392867a-00%40eu-central-1.amazonses.com.

Re: [Django] #35434: prefetch_related_objects fails to cache UUID FKs when the string representation of a UUID is used

[Django]

#35434: prefetch_related_objects fails to cache UUID FKs when the string
representation of a UUID is used
-+-
 Reporter:  Selcuk Ayguney   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 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 Selcuk Ayguney):

 Replying to [comment:11 Jacob Walls]:
 > Selcuk, is it okay if I reframe your ticket as a documentation request
 and ask for another opinion?
 It's perfectly fine. Simon has a good point, and I agree that it is easy
 to handle this on the application side.
-- 
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/0107018f4bcce51f-4d433766-5dd0-4352-91b0-4f3237a7c79d-00%40eu-central-1.amazonses.com.

Re: [Django] #35433: NumberInput min_value attr overridden by IntegerField.widget_attrs

[Django]

#35433: NumberInput min_value attr overridden by IntegerField.widget_attrs
-+--
 Reporter:  mitch99  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  5.0
 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 mitch99):

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

Comment:

 OK thanks I'll try these approaches.
-- 
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/0107018f4c174b8b-ca9c861a-79bd-429d-ac39-b14c02c35d33-00%40eu-central-1.amazonses.com.