|auth_permission column lengths||Greg Aker||6/18/12 11:25 PM|
I wanted to bring up this bug: https://code.djangoproject.com/ticket/17763 as it's bitten me on a couple of projects recently
Summarizing the ticket:
Django automatically generates a name that is longer than what the default field length can hold.
INSERT INTO "auth_permission" ("name", "content_type_id", "codename") VALUES (%s, %s, %s) (u'Can add study plan practice assessment tutorial question', 52, u'add_studyplanpracticeassessmenttutorialquestion')
This will fail with a error about it not being able to fit in a varchar(50)
Table "public.auth_permission" Column | Type | Modifiers -----------------+------------------------+-------------------------------------------------------------- id | integer | not null default nextval('auth_permission_id_seq'::regclass) name | character varying(50 ) | not null content_type_id | integer | not null codename | character varying(100) | not null
This was under PostgreSQL and after modifying the field to have a length of 200, I was able to perform the insert.
This is easy to run into, especially when other developers who might make a particular model are working in SQLite3, where validation at the db level does not happen and values are silently truncated. It can also happen pretty easily when working with legacy database tables with overly verbose table names.
The 50/100 char length constraint on name and codename seem to be rather arbitrary to me. I think it seems reasonable to bump these up to 200 or 255, and provide validation on the lengths to be entered when performing syncdb.
I'm happy to work on a patch/tests if there is interest. For now, when a slightly longer class name is needed, the only real way around it is to alter the model & the db, which is not ideal.
Thanks in advance!
|Re: auth_permission column lengths||Florian Apolloner||6/19/12 7:12 AM|
Django itself can't change that currently since there is no support for schema alteration in Core. Once we get that we can tackle issues like that and increase to a sensible limit. (both name and codename might cause problems…).
|Re: auth_permission column lengths||Stephan Jaensch||6/19/12 7:25 AM|
Am 19.06.2012 um 16:12 schrieb Florian Apolloner:
How is this a factor if the limit exists only at the database level and is not enforced or considered in Django code? Django code already creates values that are too long for the fields. You would just eliminate this bug on new installations. In the case of usernames and email addresses, the limit was enforced in Django code, so increasing the field length could break existing installations since we can't do automatic schema migrations. But in this case, things already break since Django does not care about the field length.
|Re: auth_permission column lengths||Greg Aker||6/19/12 8:13 AM|
I don't think waiting for migrations in the Django core is totally necessary to fix a bug like this (or others that might be similar). With proper documentation in the release/upgrade notes, I think it's completely reasonable to expect someone working with Django to be able to run a manual SQL query to alter those columns.
If this is a core philosophy not to ask users to run manual queries on updates, is starting with a patch to enforce limits here a good thing?
|Re: auth_permission column lengths||Andrew Godwin||6/19/12 8:52 AM|
On 19/06/12 15:25, Stephan Jaensch wrote:>> name and codename might cause problemsï¿½).
>I agree, this is one of the few cases where it's possible to get away
without a schema migration, as the behaviour if we made this change
would be exactly the same on old installations and it would be fixed
on newer ones.
Of course, this just leads to a higher limit after which you have
values which are too long, but if your class names are getting over
200 characters long I suggest you have other issues.
|Re: auth_permission column lengths||Andrew Godwin||6/19/12 8:56 AM|
On 19/06/12 16:13, Greg Aker wrote:It's messy to ask people to manually run SQL queries to change this
stuff in general - we'd have to provide four or five different queries,
and the operation isn't even possible on SQLite (you'd have to make a
new table with the right schema and copy things over). I'm working
studiously on getting schema migration stuff in, it'll just take a
release or two till it's ready.
As for the interim solution, I replied to Stephan's post about that - I
think just increasing max_length will work well enough for now in this
case, as it's one of the few situations where the schema is slightly
decoupled from the models.
|Re: auth_permission column lengths||Greg Aker||6/19/12 9:04 AM|
Good to know about native migrations, and the interim solution seems reasonable.
Thanks so much!
|Re: auth_permission column lengths||Shai Berger||6/20/12 3:21 AM|
I have suggested, on the bug itself, a partial solution that requires no database schema change (elide the "name" field if it's too long,
as it is only used for display anyway).
The "codename" field will then stay problematic, but the limitation there is much less severe.