mirror of
https://github.com/django/django.git
synced 2025-11-18 02:56:45 +00:00
Rephrased remarks about mixing field classes/column types for clarity.
See https://github.com/django/django/pull/20091#discussion_r2523424284
This commit is contained in:
parent
6fb854e183
commit
f43e51490e
1 changed files with 6 additions and 5 deletions
|
|
@ -529,9 +529,10 @@ Should become::
|
|||
uuid = Char32UUIDField(primary_key=True, default=uuid.uuid4)
|
||||
|
||||
Running the :djadmin:`makemigrations` command will generate a migration
|
||||
containing a no-op ``AlterField`` operation. Since any new ``UUIDField``
|
||||
would use a ``UUID`` column, the ``Char32UUIDField`` should be used
|
||||
instead, when mixing column types is not desired.
|
||||
containing a no-op ``AlterField`` operation. By default, new
|
||||
``UUIDField`` instances will use the ``UUID`` column type: To ensure
|
||||
consistency with existing fields, use ``Char32UUIDField`` instead for
|
||||
new fields that should have the same column type.
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -551,8 +552,8 @@ a data migration::
|
|||
)
|
||||
]
|
||||
|
||||
This would avoid potentially mixing the old and new column types and
|
||||
needs no additional consideration on new fields, once migrated.
|
||||
Once migrated, this would need no additional consideration when adding
|
||||
new ``UUIDField`` instances.
|
||||
|
||||
Please note that for larger tables or when ``UUIDFields`` are used as
|
||||
primary keys or in constraints, this operation could either require a
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue