Changes between Version 1 and Version 2 of Ticket #37238
- Timestamp:
- Jul 28, 2026, 3:51:18 PM (63 minutes ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #37238 – Description
v1 v2 1 When saving an object whose primary key is a `OneToOneField`, and when that value is meant to come from an unsaved related object, and when that related object uses `db_default`, a2348c85fc6c20087935c74cd99340dd4ef2dcdc has the unintentional effect of falling back to the field's `default` instead of getting it from the related object once saved. 1 When saving an object whose primary key is a `OneToOneField`, and when that value is meant to come from an unsaved related object, and when that related object uses `db_default`, a2348c85fc6c20087935c74cd99340dd4ef2dcdc has the unintentional effect of falling back to the field's `default` instead of getting it from the related object once saved. EDIT: before 6.1, the fallback was to the related object's db_default expression, which isn't quite right either, so my current proposal is to just match the 6.0 behavior and then bounce the rest to a follow-up issue. 2 2 3 3 To demonstrate, adjust a test being drafted in this [https://github.com/django/django/pull/21677 other PR] (where the `bulk_create()` case was considered and handled) to use `save()` instead: 4 4 5 Passes before a2348c85fc6c20087935c74cd99340dd4ef2dcdc on SQLite. Other databases have other behaviors, like raising integrity errors, so we might need some test skips here. 5 Passes before a2348c85fc6c20087935c74cd99340dd4ef2dcdc on SQLite. Other databases have other behaviors, like raising integrity errors, so we might need some test skips here. This should be rewritten to use Now() instead of a constant value; I found the constant value was easier to debug. 6 6 7 7 {{{#!diff