Opened 16 years ago

Closed 10 years ago

Last modified 8 years ago

#8548 closed Bug (fixed)

Lengthy verbose_name results in fatal mysql 'warning' error during syncdb.

Reported by: samt@… Owned by: Marcelo Ramos
Component: Core (Management commands) Version: 1.4
Severity: Normal Keywords:
Cc: thepapermen, markus@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description (last modified by Malcolm Tredinnick)

class Thingie(models.Model)
#fields go here
  class Meta:
    verbose_name = 'A String Greater Than 50 Characters Long, Probably For The Admin'

Running 'python syncdb' results in MySQLdb trying to run the following:

INSERT INTO `auth_permission` (`name`, `content_type_id`, `codename`) VALUES (%s, %s, %s)(u'A String Greater Than 50 Characters Long, Probably For The Admin', 11, u'add_thingie')

The field name has a length restriction of 50 characters. This results in a warning 'error' being generated (_mysql_exceptions.Warning: Data truncated for column 'name' at row 1) but no further useful information. This also halts syncdb, which is also called during the test suite.

Suggestions (since I'm nowhere near qualified to contribute, yet):

  • Maybe just catch the warning and ignore it? This seems to be a display-only field, so it probably won't hurt.
  • Or maybe catch the warning and explain the cause?
  • Model validator could complain about verbose_name being too long?
  • Increase the size of the field?
  • Maybe just let google index this ticket so that the next person to google the error sees why it happened?
Traceback (most recent call last):
  File "", line 11, in <module>
  File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/", line 334, in execute_manager
  File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/", line 295, in execute
  File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/", line 77, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/", line 96, in execute
    output = self.handle(*args, **options)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/", line 178, in handle
    return self.handle_noargs(**options)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/commands/", line 101, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/core/management/", line 205, in emit_post_sync_signal
  File "/usr/local/python-x/lib/python2.5/site-packages/django/dispatch/", line 148, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/contrib/auth/management/", line 28, in create_permissions
    defaults={'name': name, 'content_type': ctype})
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/", line 84, in get_or_create
    return self.get_query_set().get_or_create(**kwargs)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/", line 331, in get_or_create
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/", line 282, in save
    self.save_base(force_insert=force_insert, force_update=force_update)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/", line 356, in save_base
    result = manager._insert(values, return_id=update_pk)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/", line 126, in _insert
    return insert_query(self.model, values, **kwargs)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/", line 884, in insert_query
    return query.execute_sql(return_id)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/sql/", line 308, in execute_sql
    cursor = super(InsertQuery, self).execute_sql(None)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/models/sql/", line 1641, in execute_sql
    cursor.execute(sql, params)
  File "/usr/local/python-x/lib/python2.5/site-packages/django/db/backends/", line 20, in execute
    return self.cursor.execute(sql, params)
  File "/usr/local/python-x/lib/python2.5/site-packages/MySQL_python-1.2.2-py2.5-macosx-10.5-i386.egg/MySQLdb/", line 168, in execute
  File "/usr/local/python-x/lib/python2.5/site-packages/MySQL_python-1.2.2-py2.5-macosx-10.5-i386.egg/MySQLdb/", line 82, in _warning_check
  File "/usr/local/python-x/lib/python2.5/", line 62, in warn
  File "/usr/local/python-x/lib/python2.5/", line 102, in warn_explicit
    raise message
_mysql_exceptions.Warning: Data truncated for column 'name' at row 1

Attachments (4)

validate_verbose_8564.diff (629 bytes ) - added by Adam Vandenberg 16 years ago.
Initial stab at a patch.
validate_verbose_8564.2.diff (676 bytes ) - added by Marcelo Ramos 15 years ago.
Modified patch with more informative error message.
ticket8548.tgz (2.4 KB ) - added by Marcelo Ramos 15 years ago.
Simple project to test the patch.
validate_verbose_name-8548-test.diff (1.5 KB ) - added by Marcelo Ramos 15 years ago.
Patch to add a test in modeltests/invalid_models

Download all attachments as: .zip

Change History (28)

comment:1 by Malcolm Tredinnick, 16 years ago

Component: Database
Description: modified (diff)
milestone: post-1.0
Triage Stage: UnreviewedAccepted

(Fixed description. The preview button is your friend.)

This problem should be caught by the validate command for That's the most logical fix.

by Adam Vandenberg, 16 years ago

Attachment: validate_verbose_8564.diff added

Initial stab at a patch.

comment:2 by Adam Vandenberg, 16 years ago

Has patch: set
Needs tests: set

comment:3 by Malcolm Tredinnick, 16 years ago

Patch needs improvement: set

Looks like a reasonable start, but just telling the user that they made a mistake is not particularly helpful. They are going to be wondering how to fix it or what the correct maximum would be. Let's give them that information in the error message.

comment:4 by anonymous, 15 years ago

Owner: changed from nobody to anonymous
Status: newassigned

The longest prefixes for the string value in the column are "Can change " and "Can delete ", both with 11 characters. The column maximum length is 50 so the maximum length of Meta.verbose_name is 39.

Modified the patch using 39 as the upper limit. Modified the error message to truncate the verbose_name value to the first 39 characters and informed the user about that limit.

I attach the modified patch and a Test Project with two models, one has a verbose_name length 39 (allowed max) and the other with length 40.

comment:5 by Marcelo Ramos, 15 years ago

Owner: changed from anonymous to Marcelo Ramos
Status: assignednew

Sorry, forgot to login before submitting.

by Marcelo Ramos, 15 years ago

Modified patch with more informative error message.

by Marcelo Ramos, 15 years ago

Attachment: ticket8548.tgz added

Simple project to test the patch.

comment:6 by Marcelo Ramos, 15 years ago

Status: newassigned

comment:7 by Marcelo Ramos, 15 years ago

Where in the test suite can i add tests for this patch?

comment:8 by Russell Keith-Magee, 15 years ago

The invalid_models regression test is the right place to check that the right validation errors are thrown.

comment:9 by (none), 15 years ago

milestone: post-1.0

Milestone post-1.0 deleted

by Marcelo Ramos, 15 years ago

Patch to add a test in modeltests/invalid_models

comment:10 by Marcelo Ramos, 15 years ago

Needs tests: unset

comment:11 by Marcelo Ramos, 15 years ago

Thanks russelm.

comment:12 by Thomas Güttler, 15 years ago

Related #4748 "Increase length of names of permissions"

comment:13 by anonymous, 14 years ago

any changes?

comment:14 by Luke Plant, 13 years ago

Severity: Normal
Type: Bug

comment:15 by thepapermen, 13 years ago

Cc: thepapermen added
Easy pickings: unset

comment:16 by anonymous, 13 years ago

UI/UX: unset

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.

comment:17 by jbonnett, 13 years ago

Resolution: worksforme
Status: assignedclosed

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.

comment:18 by Karen Tracey, 13 years ago

Resolution: worksforme
Status: closedreopened

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.

comment:19 by mdeboard, 13 years ago

Version: 1.0-beta-11.3

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.


comment:20 by cdoussin@…, 11 years ago

Version: 1.31.4

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.

comment:21 by Aymeric Augustin, 11 years ago

Status: reopenednew

comment:22 by Markus Zapke-Gründemann, 11 years ago

Cc: markus@… added

comment:23 by Claude Paroz, 10 years ago

Resolution: fixed
Status: newclosed

I think that the fix for #18866 also resolved this issue. #8162 is used to track permission name length.

comment:24 by Simon Charette <charette.s@…>, 8 years ago

In 7b8e454:

Refs #8548 -- Removed a workaround for lengthy verbose name.

Note: See TracTickets for help on using tickets.
Back to Top