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

2024-05-07 Thread Django
#35425: .save(force_update=True) not respected for model instances with default
primary keys
-+-
 Reporter:  Jacob Walls  |Owner:  Jacob
 |  Walls
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce <42296566+sarahboyce@…>):

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

Comment:

 In [changeset:"ceea86baa36b91d0002911770340a2d7bd4f64b7" ceea86b]:
 {{{#!CommitTicketReference repository=""
 revision="ceea86baa36b91d0002911770340a2d7bd4f64b7"
 Fixed #35425 -- Avoided INSERT with force_update and explicit pk.

 Affected models where the primary key field is defined with a
 default or db_default, such as UUIDField.
 }}}
-- 
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/0107018f528d24ec-b78d1021-54a4-4705-b75e-60bab6661090-00%40eu-central-1.amazonses.com.


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

2024-05-06 Thread 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:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * 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/0107018f4d4cb295-4f24e31c-e04a-4d1f-b9b3-e0bb214b49d5-00%40eu-central-1.amazonses.com.


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

2024-05-05 Thread 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] #35425: .save(force_update=True) not respected for model instances with default primary keys

2024-05-04 Thread 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:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jacob Walls):

 * has_patch:  0 => 1

Comment:

 [https://github.com/django/django/pull/18131 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/0107018f457d1020-3be0ca2e-24de-4f4a-b8f5-297cd204de41-00%40eu-central-1.amazonses.com.


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

2024-05-03 Thread 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:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Jacob Walls:

Old description:

> With this model,
> {{{
> class WithDefault(models.Model):
> id = models.UUIDField(primary_key=True, default=uuid.uuid4)
> message = models.CharField(null=True)
> }}}
>
> the first IntegrityError at line 5 is expected as of
> https://code.djangoproject.com/ticket/29260#comment:3, but the second one
> at line 6, I suggest, is not.
>
> {{{
> In [1]: from models import WithDefault
>
> In [2]: import uuid
>
> In [3]: known_uuid = uuid.uuid4()
>
> In [4]: WithDefault.objects.create(pk=known_uuid)
> Out[4]:  8f9091d9ebdc)>
>
> In [5]: WithDefault(pk=known_uuid, message="overwritten").save()
> ---
> UniqueViolation   Traceback (most recent call
> last)
>
> UniqueViolation: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
>
> ...
> IntegrityError: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
>

> In [6]: WithDefault(pk=known_uuid,
> message="overwritten").save(force_update=True)
> ---
> UniqueViolation   Traceback (most recent call
> last)
> File ~/django/django/db/backends/utils.py:105, in
> CursorWrapper._execute(self, sql, params, *ignored_wrapper_args)
> 104 else:
> --> 105 return self.cursor.execute(sql, params)
>
> UniqueViolation: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
>

> The above exception was the direct cause of the following exception:
>
> IntegrityErrorTraceback (most recent call
> last)
> Cell In[6], line 1
> > 1 WithDefault(pk=known_uuid,
> message="overwritten").save(force_update=True)
>
> File ~/django/django/db/models/base.py:1185, in Model._do_insert(self,
> manager, using, fields, returning_fields, raw)
>1180 def _do_insert(self, manager, using, fields, returning_fields,
> raw):
>1181 """
>1182 Do an INSERT. If returning_fields is defined then this method
> should
>1183 return the newly created data for the model.
>1184 """
> -> 1185 return manager._insert(
>1186 [self],
>1187 fields=fields,
>1188 returning_fields=returning_fields,
>1189 using=using,
>1190 raw=raw,
>1191 )
> ...
> IntegrityError: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
> }}}
>

> 
>
> I had an illuminating [https://forum.djangoproject.com/t/save-behavior-
> when-updating-model-with-default-primary-keys/30778 conversation on the
> forum] regarding my surprise at the behavior of `save()` when dealing
> with the first failure on line 5. Stating what I learned from it in case
> helpful.
>
> Until yesterday, I thought that the following two calls were equivalent,
> other than perhaps one being faster for updates and the other faster for
> inserts. In fact, I thought this equivalence would have been a nice
> clarification of the value prop of the ORM that
> “[https://docs.djangoproject.com/en/5.0/ref/models/instances/#how-django-
> knows-to-update-vs-insert Django abstracts] the need to use INSERT or
> UPDATE SQL statements.” In other words, what does `save()` do? ''It
> updates or creates.''
>
> {{{
> def overwrite_1(known_uuid):
> MyModel.objects.update_or_create(
> pk=known_uuid,
> defaults={
> "other_field": 1,
> },
> )
>
> def overwrite_2(known_uuid):
> MyModel(
> pk=known_uuid,
> other_field=1,
> ).save()
> }}}
>
> So, at least when I'm in an overwriting posture--and Ken brings up a good
> point that [https://forum.djangoprojec

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

2024-05-03 Thread 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:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Jacob Walls:

Old description:

> With this model,
> {{{
> class WithDefault(models.Model):
> id = models.UUIDField(primary_key=True, default=uuid.uuid4)
> message = models.CharField(null=True)
> }}}
>
> the first IntegrityError at line 5 is expected as of
> https://code.djangoproject.com/ticket/29260#comment:3, but the second one
> at line 6, I suggest, is not.
>
> {{{
> In [1]: from models import WithDefault
>
> In [2]: import uuid
>
> In [3]: known_uuid = uuid.uuid4()
>
> In [4]: WithDefault.objects.create(pk=known_uuid)
> Out[4]:  8f9091d9ebdc)>
>
> In [5]: WithDefault(pk=known_uuid, message="overwritten").save()
> ---
> UniqueViolation   Traceback (most recent call
> last)
>
> UniqueViolation: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
>
> ...
> IntegrityError: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
>

> In [6]: WithDefault(pk=known_uuid,
> message="overwritten").save(force_update=True)
> ---
> UniqueViolation   Traceback (most recent call
> last)
> File ~/django/django/db/backends/utils.py:105, in
> CursorWrapper._execute(self, sql, params, *ignored_wrapper_args)
> 104 else:
> --> 105 return self.cursor.execute(sql, params)
>
> UniqueViolation: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
>

> The above exception was the direct cause of the following exception:
>
> IntegrityErrorTraceback (most recent call
> last)
> Cell In[6], line 1
> > 1 WithDefault(pk=known_uuid,
> message="overwritten").save(force_update=True)
>
> File ~/django/django/db/models/base.py:1185, in Model._do_insert(self,
> manager, using, fields, returning_fields, raw)
>1180 def _do_insert(self, manager, using, fields, returning_fields,
> raw):
>1181 """
>1182 Do an INSERT. If returning_fields is defined then this method
> should
>1183 return the newly created data for the model.
>1184 """
> -> 1185 return manager._insert(
>1186 [self],
>1187 fields=fields,
>1188 returning_fields=returning_fields,
>1189 using=using,
>1190 raw=raw,
>1191 )
> ...
> IntegrityError: duplicate key value violates unique constraint
> "models_withdefault_pkey"
> DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
> }}}
>

> 
>
> I had an illuminating [https://forum.djangoproject.com/t/save-behavior-
> when-updating-model-with-default-primary-keys/30778 conversation on the
> forum] regarding my surprise at the behavior of `save()` when dealing
> with the first failure on line 5. Stating what I learned from it in case
> helpful.
>
> Until yesterday, I thought that the following two calls were equivalent,
> other than perhaps one being faster for updates and the other faster for
> inserts. In fact, I thought this equivalence would have been a nice
> clarification of the value prop of the ORM that
> “[https://docs.djangoproject.com/en/5.0/ref/models/instances/#how-django-
> knows-to-update-vs-insert Django abstracts] the need to use INSERT or
> UPDATE SQL statements.” In other words, what does `save()` do? ''It
> updates or creates.''
>
> {{{
> def overwrite_1(known_uuid):
> MyModel.objects.update_or_create(
> pk=known_uuid,
> defaults={
> "other_field": 1,
> },
> )
>
> def overwrite_2(known_uuid):
> MyModel(
> pk=known_uuid,
> other_field=1,
> ).save()
> }}}
>
> So, at least when I'm in an overwriting posture--and Ken brings up a good
> point that [https://forum.djangoprojec

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

2024-05-03 Thread Django
#35425: .save(force_update=True) not respected for model instances with default
primary keys
-+-
   Reporter:  Jacob  |  Owner:  Jacob Walls
  Walls  |
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  4.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  |
-+-
 With this model,
 {{{
 class WithDefault(models.Model):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4)
 message = models.CharField(null=True)
 }}}

 the first IntegrityError at line 5 is expected as of
 https://code.djangoproject.com/ticket/29260#comment:3, but the second one
 at line 6, I suggest, is not.

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

 In [2]: import uuid

 In [3]: known_uuid = uuid.uuid4()

 In [4]: WithDefault.objects.create(pk=known_uuid)
 Out[4]: 

 In [5]: WithDefault(pk=known_uuid, message="overwritten").save()
 ---
 UniqueViolation   Traceback (most recent call
 last)

 UniqueViolation: duplicate key value violates unique constraint
 "models_withdefault_pkey"
 DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.

 ...
 IntegrityError: duplicate key value violates unique constraint
 "models_withdefault_pkey"
 DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.


 In [6]: WithDefault(pk=known_uuid,
 message="overwritten").save(force_update=True)
 ---
 UniqueViolation   Traceback (most recent call
 last)
 File ~/django/django/db/backends/utils.py:105, in
 CursorWrapper._execute(self, sql, params, *ignored_wrapper_args)
 104 else:
 --> 105 return self.cursor.execute(sql, params)

 UniqueViolation: duplicate key value violates unique constraint
 "models_withdefault_pkey"
 DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.


 The above exception was the direct cause of the following exception:

 IntegrityErrorTraceback (most recent call
 last)
 Cell In[6], line 1
 > 1 WithDefault(pk=known_uuid,
 message="overwritten").save(force_update=True)

 File ~/django/django/db/models/base.py:1185, in Model._do_insert(self,
 manager, using, fields, returning_fields, raw)
1180 def _do_insert(self, manager, using, fields, returning_fields,
 raw):
1181 """
1182 Do an INSERT. If returning_fields is defined then this method
 should
1183 return the newly created data for the model.
1184 """
 -> 1185 return manager._insert(
1186 [self],
1187 fields=fields,
1188 returning_fields=returning_fields,
1189 using=using,
1190 raw=raw,
1191 )
 ...
 IntegrityError: duplicate key value violates unique constraint
 "models_withdefault_pkey"
 DETAIL:  Key (id)=(0ccbf1df-6296-4efe-8f5d-8f9091d9ebdc) already exists.
 }}}


 

 I had an illuminating [https://forum.djangoproject.com/t/save-behavior-
 when-updating-model-with-default-primary-keys/30778 conversation on the
 forum] regarding my surprise at the behavior of `save()` when dealing with
 the first failure on line 5. Stating what I learned from it in case
 helpful.

 Until yesterday, I thought that the following two calls were equivalent,
 other than perhaps one being faster for updates and the other faster for
 inserts. In fact, I thought this equivalence would have been a nice
 clarification of the value prop of the ORM that
 “[https://docs.djangoproject.com/en/5.0/ref/models/instances/#how-django-
 knows-to-update-vs-insert Django abstracts] the need to use INSERT or
 UPDATE SQL statements.” In other words, what does `save()` do? ''It
 updates or creates.''

 {{{
 def overwrite_1(known_uuid):
 MyModel.objects.update_or_create(
 pk=known_uuid,
 defaults={
 "other_field": 1,
 },
 )

 def overwrite_2(known_uuid):
 MyModel(
 pk=known_uuid,
 other_field=1,
 ).save()
 }}}

 So, at least when I'm in an overwriting posture--and Ken brings up a good
 point that [https://forum.djangoproject.com/t/save-behavior-when-updating-
 model-with-default-primary-keys/30778/9 forcing the user to opt in to this
 potential for data loss] for existing primary keys is worth something--I
 prefer `save()`. It's simpler and doesn't involve "defaults". (''What's a
 "default" got to do with updat