* owner: nobody => Coumes Quentin
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/34183#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
This would make the definition of field's {{{max_length}}} easier as well
as automatically create a new migration when deleting/adding members which
would change the {{{max_length}}}.
If the data type does not support {{{len()}}, it could raise
{{{TypeError}}} (same exception raise by {{{len}}}) something like :
{{{
raise TypeError("Can only compute max_length on data type supporting
len()")
}}}
I can do the patch if this feature does make sense to you.
--
Ticket URL: <https://code.djangoproject.com/ticket/34183>
Old description:
> It would be helpful for enums inheriting {{{Choices}}} with a data type
> supporting {{{len()}}} to be able to compute {{{max_length}}} by
> themselves.
>
> This would make the definition of field's {{{max_length}}} easier as well
> as automatically create a new migration when deleting/adding members
> which would change the {{{max_length}}}.
>
> If the data type does not support {{{len()}}, it could raise
> {{{TypeError}}} (same exception raise by {{{len}}}) something like :
>
> {{{
> raise TypeError("Can only compute max_length on data type supporting
> len()")
> }}}
>
> I can do the patch if this feature does make sense to you.
New description:
It would be helpful for enums inheriting {{{Choices}}} with a data type
supporting {{{len()}}} to be able to compute {{{max_length}}} by
themselves.
This would make the definition of field's {{{max_length}}} easier as well
as automatically create a new migration when deleting/adding members which
would change the {{{max_length}}}.
If the data type does not support {{{len()}}}, it could raise
{{{TypeError}}} (same exception raise by {{{len}}}) something like :
{{{
raise TypeError("Can only compute max_length on data type supporting
len()")
}}}
I can do the patch if this feature does make sense to you.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34183#comment:2>
* status: assigned => closed
* resolution: => wontfix
* component: Utilities => Database layer (models, ORM)
Comment:
Thanks for this ticket, however this would be highly fragile and error
prone. First of all, removing an option from choices doesn't guarantee
that it will not used by existing rows, so such migrations will quite
often crash, or worse, the database may truncate existing data and create
values that don't match `choices` (some database automatically truncate
data when precision is changed). Secondly, altering a precision is a
locking DDL operation, so it can be really disruptive for users to perform
it after each change in `choices`.
You can start a discussion on DevelopersMailingList, if you don't agree.
--
Ticket URL: <https://code.djangoproject.com/ticket/34183#comment:3>