Changes between Version 5 and Version 6 of Ticket #23408, comment 6


Ignore:
Timestamp:
Nov 25, 2014, 2:35:53 PM (10 years ago)
Author:
Michael Barr

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #23408, comment 6

    v5 v6  
    6060If default is set to a callable, I believe that it is implied that the result should be dynamically generated in Python/Django. If the functionality is to stay as stated in the result of this ticket, I would have to hand-code this migration for each app that previously existed to first create a nullable UUIDField with no default, then create a data migration to add distinct UUIDs to the Company, then write a migrations.AlterField migration to set null=False. The alternative might be to consider creating a special case for the UUIDField to allow for non-duplicated UUIDs to be created during migrations.
    6161
    62 From what I can take away, it has been stated that you cannot add/alter a field with a default=callable() null=False, unique=True without writing a custom migration. I would be much easier for if migrations followed the same standards as the [https://github.com/django/django/blob/1.7.1/django/db/models/fields/__init__.py#L713 django.db.models.fields.Field.get_default()] method. Currently, we have to hand-code the following migration to avoid the failure for every app which utilizes the AbstractUUIDModel, which I feel violates the DRY principle:
     62From what I can take away, it has been stated that you cannot add/alter a field with a default=callable(), null=False, unique=True without writing a custom migration. I would be much easier for if migrations followed the same standards as the [https://github.com/django/django/blob/1.7.1/django/db/models/fields/__init__.py#L713 django.db.models.fields.Field.get_default()] method. Currently, we have to hand-code the following migration to avoid the failure for every app which utilizes the AbstractUUIDModel, which I feel violates the DRY principle:
    6363{{{
    6464# -*- coding: utf-8 -*-
Back to Top