On Tuesday, March 20, 2012 at 1:07 PM, Nan wrote: > > > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > >
What Alex said. If it was _just_ the username then you'd have a good argument for a setting like that. However there's username, email, some people want to add fields, some want to get rid of, or combine fields. Ideally any change would work for as many of those use cases without turning into a giant set of boolean flags that drastically alter the DB schema. -- 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.
