> 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.
>
There other way do do this.
For example tunning of User model can done by configuration, like that:
EXTENDED_USERMODEL_SETTINGS = {'email':
{'uniq':True,'max_length':255,
'field_type':EmailField},
'first_name': None,
'last_name': None,
'name': CharField
}
This create unique email field with length of 255 chars and alter fields
first_name, last_name and change them to name field. But this is not very
flexible, and similar to create own User model from base class.
Also i think that change model in the settings is not good idea.
I thought about a lot of ideas how it can be done, and i think that the best
way to do this is to allow user define there own User model.
For do this easy need divide auth.user into two parts -- one is the Basics
abstract classes, and other is real models that store in database.
For compatibility by default models.User have the same definition as it
was in
old versions but it can be inherited from abstract class, for new
application
that need some extended UserModel with same behavior it also good to define
new UserModel with support long emails and other good things.
For compatibility UserModel that choice user can be found in
auth.models.User
for application that use relations with User model.
Also i thin that permission must remain in auth application and need some
extend it. Django support object permission in auth backends but i think it
need extend features of object permissions. Also it is good add template tag
for checking permissions in template.
Sorry i am little a bit away from topic.
There were good if the User model would have an extend interface, for
example
setting the the special form for auth that may use some application, for
example django admin for login users. But forms for auth can be set in other
way, but it need for some application like django.admin.
P.S I am working on my proposal for GSOC auth.user.
--
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.
