#23861: Fields referenced in migrations cannot be (re)moved, even if migrations
have been squashed
---------------------------------+------------------------------------
     Reporter:  spookylukey      |                    Owner:  nobody
         Type:  Bug              |                   Status:  new
    Component:  Migrations       |                  Version:  master
     Severity:  Release blocker  |               Resolution:
     Keywords:                   |             Triage Stage:  Accepted
    Has patch:  0                |      Needs documentation:  0
  Needs tests:  0                |  Patch needs improvement:  0
Easy pickings:  0                |                    UI/UX:  0
---------------------------------+------------------------------------

Comment (by MarkusH):

 While looking at Tim's patch for #23891 I came up with the following:

 {{{#!python
 class Field(...):
     deprecated_for_migrations = False
     removed_for_migrations = False

     def check(...):
         # ...
         errors.extend(self._check_migration_availability(...))
         # ...

     def _check_migration_availability(self):
         if self.__class__.removed_for_migrations:
             return [
                 checks.Error(
                     'The field %s has been removed except for support in
 historical migrations.' % self.__class__.__name__,
                     hint=None,
                     obj=self,
                     id='fields.EXXX',
                 )
             ]
         elif self.__class__.deprecated_for_migrations:
             return [
                 checks.Warning(
                     'The field %s has been deprecated. Support for it
 (except in historical migrations) will be removed according to the
 deprecation timeline' % self.__class__.__name__,
                     hint=None,
                     obj=self,
                     id='fields.WXXX',
                 )
             ]

 class IPAddressField(...):
     deprecated_for_migrations = True
 }}}

 This comes with one drawback that Tim correctly noted:

 > It seems nice to be able to have a unique code for each field so they
 can be silenced if desired, rather than one code for all deprecations, but
 this seems possible only if we use the model field class name to generate
 the code, in which case we'll have to depart from the usual numbering
 scheme.

--
Ticket URL: <https://code.djangoproject.com/ticket/23861#comment:14>
Django <https://code.djangoproject.com/>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.8def772d4133d7165971378724b5cddb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to