As for instance per bug #17870, email-addresses can be as long as 254
bytes. Today, the length of the EmailField is less than that. If
django is to be RFC-compliant in this respect, we will need to come up
with a way to migrate existing email-fields to the new length.
1. Migration in general
No matter how we technically wind up doing that there ought to be a
standard "social" process for turning migrations on and off, so that
the time and date for the migration can be chosen by devops. Python
itself has the slightly magic module named __future__. In the spirit
of this I propose *one* setting for turning migrations on and off, the
actual name is not very important.
Using EmailField as en example:
MIGRATION_OPTIONS = ('rfc_email_addresses',)
MIGRATION_OPTIONS is by default empty. Setting it, and running a
single command, say "python manage.py migrate" runs whatever technical
means to do the migration. There should probably be a list kept
somewhere over which migrations have already been run, for
efficiency's sake if nothing else. The migrate-command does all that
can be done automatically without user intervention, and documents
anything that may or must be done manually.
The migrate-command only cares about keys it knows about, in this case
"rfc_email_addresses", and ignores anything else in the iterable. No
need to change the settings after the migration is done, and it serves
as a documentation of what migrations have already been done :)
If we can get this in for 1.5, people can migrate email-addresses in
1.5, and the migrate-command would forget about "rfc_email_addresses"
one version after the new email-fields became mandatory.
2. Migration in this specific case
Let's just do it. Let's not wait for a generic migration tool! I'd
rather the energy was spent on the app-refactor *now*, and fixing the
email-fields *now*, which would remove some of the pressure on fixing
the Identity/Authentication/Authorization architecture.
Go through all models in all apps, discover the email-fields, and run
an ALTER TABLE <tablename> ALTER COLUMN <columnname> TYPE varchar(254)
on each, and if that is not supported, add a column, copy old to new,
drop the old column.
HM
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
