Re: [Django] #8548: Lengthy verbose_name results in fatal mysql 'warning' error during syncdb.
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Type: Bug | Status: assigned
Milestone: | Component: Core (Management
Version: | commands)
1.0-beta-1 | Severity: Normal
Resolution: | Keywords:
Triage Stage: Accepted | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 1 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by anonymous):
* ui_ux: => 0
Comment:
The resolution to ticket #4748 is nonsensical. How would *increasing* the
length of the field break backwards compatibility? Any working application
in production up to this point logically must have all auth_permissions
character lengths of below 50 right now, making it a decidedly backwards
compatible change. If those apps that are in production add an auth
permission that has a length of greater than 50 in the future, then yes,
they would have to manually change it in the DB, but that is preferable to
making EVERY user with this issue manually change their DB.
This seems to me to be a case where a developer is hiding behind a
technicality to push off a change that fixes broken functionality.
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:16>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Version: | commands)
1.0-beta-1 | Severity: Normal
Resolution: | Keywords:
Triage Stage: Accepted | Needs tests: 0
Needs documentation: 0 | Easy pickings: 0
Patch needs improvement: 1 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by jbonnett):
* status: assigned => closed
* resolution: => worksforme
Comment:
I have tried to replicate this behavior on trunk and so far I am having no
luck. The test model fails to raise a error on sqlite and mysql. If there
is no longer a error, providing a error nicer error message is moot. If I
am wrong and this is still a problem, by all means let me know, i would be
happy to take a crack at updating the patch.
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:17>
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Version: | commands)
1.0-beta-1 | Severity: Normal
Resolution: | Keywords:
Patch needs improvement: 1 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Changes (by kmtracey):
* status: closed => reopened
* resolution: worksforme =>
Comment:
This is still re-creatable by me with a brand new MySQL database. I don't
imagine it would ever be re-creatable on sqlite: sqlite simply doesn't
enforce length restrictions. On MySQL whether it is a warning or an error
condition is determined by the strictness mode set. If MySQL is configured
to consider it just a warning situation, it's possible that the data will
just get truncated with a warning being printed at the console; Django
only turns MySQL warnings into exceptions when the DEBUG setting is True.
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:18>
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Type: Bug | Status: reopened
commands) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by mdeboard):
* version: 1.0-beta-1 => 1.3
Comment:
I can verify this problem is persistent in Django 1.3, MySQL 5.1.58.
Specifically I encounter it:
1. Trying to load the fixture from django-countria
2. Saving tags using Django-taggit
3. Any place where the specified field length is shorter than the
attempted input.
The error handling for this particular issue is very frustrating. The only
solution (afaik) is to either reconfigure MySQL to consider it a warning
or to subclass the models in question and increase the max_length of the
field. This is fine, however a more explanatory error message to alert
users to this fact is called for, in my opinion.
Thanks,
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:19>
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Type: Bug | Status: reopened
commands) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* version: 1.3 => 1.4
Comment:
This is also an issue with long model names of 6-7 words and up (and
verbose names automatically generated from the model name). For example I
just hit the issue with
"PremiumAppSubscriptionIncludedIssueCreditProduct".
When you look at the MySQL table, the length of the fields doesn't make
sense for long model names: name is half as short as codename, when the
codename values are bound to be a bit shorter than the verbose name
values.
mysql> describe auth_permission;
+-----------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| name | varchar(50) | NO | | NULL | |
| content_type_id | int(11) | NO | MUL | NULL | |
| codename | varchar(100) | NO | | NULL | |
+-----------------+--------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)
As a result, I would be in favour of increasing the length of the "name"
field.
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:20>
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Component: Core (Management | Version: 1.4
commands) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* cc: markus@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:22>
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Component: Core (Management | Version: 1.4
Severity: Normal | Triage Stage: Accepted
Keywords: | Needs documentation: 0
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => fixed
Comment:
I think that the fix for #18866 also resolved this issue. #8162 is used to
track permission name length.
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:23>
Django
-------------------------------------+-------------------------------------
Reporter: samt@… | Owner: marcelor
Type: Bug | Status: closed
Component: Core (Management | Version: 1.4
commands) |
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Simon Charette <charette.s@…>):
In [changeset:"7b8e4545c3521c6081db993ed2c14daa277d8dd9" 7b8e454]:
{{{
#!CommitTicketReference repository=""
revision="7b8e4545c3521c6081db993ed2c14daa277d8dd9"
Refs #8548 -- Removed a workaround for lengthy verbose name.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/8548#comment:24>