> However not all databases have this same behavior when trying to insert a
> string that is longer than
> the field allows. This means that for a certain subset of Django developers
> if they didn't read the
> releases note, or just missed that section of it that Django would not
> validate the length of the
> field to be 30, but would instead validate it to be much longer, Django would
> pass it to the database
> who for those users it would silently truncate the data.
Would something like the following alleviate that problem?
class User(models.Model):
if settings.USE_LONG_USER_FIELDS:
username = models.CharField(max_length=255, unique=True, ...)
else:
username = models.CharField(max_length=30, unique=True, ...)
...
So you have three cases:
1) New app; settings.py generated with USE_LONG_USER_FIELDS=True;
table generated with full-length fields on syncdb; no problem.
2) Existing app; user doesn't read the docs, doesn't change settings;
field still gets set to max_length=30, no data loss
3) Existing app; user reads the docs, changes the settings, and
updates his database.
This way you'd only get data loss if someone manages to read the docs
closely enough to update the settings but not the DB, which IMO is
something that gets addressed by calling it out very clearly in the
documentation anywhere the setting is mentioned.
Just an idea...
-Nan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
