Changes between Initial Version and Version 1 of Ticket #36225, comment 11


Ignore:
Timestamp:
Sep 25, 2025, 10:42:17 AM (39 hours ago)
Author:
Jacob Walls

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #36225, comment 11

    initial v1  
    11Reopened #35729 as a usability issue in the serialization framework that model subclasses cannot opt out of natural key serialization.
    22
    3 This issue was opened after OP bit the bullet and reimplemented the User model from scratch. I agree it's not correct for createsuperuser to deduce from `field.unique` that you can `get_by_natural_key()`, since there could be a use case for omitting an implementation as doc'd:
     3This issue was opened after OP bit the bullet and reimplemented the User model from scratch. I agree it's not correct for createsuperuser to deduce from `field.unique` that we've doc'd that you can deliberately omit `get_by_natural_key()` and also doc'd that USERNAME_FIELD can be non-unique.
    44
    5 > Conversely, if (for some strange reason) you want Django to output natural keys during serialization, but not be able to load those key values, just don’t define the get_by_natural_key() method.
    6 
    7 "strange" or not, given we've doc'd it, I think it's reasonable for `createsuperuser` to catch `AttributeError`.
     5Catching `AttributeError` here seems reasonable.
Back to Top