Re: auth_permission column lengths

[Florian Apolloner]

Hi Greg,

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…).

Cheers,
Florian

[Stephan Jaensch]

Hi Florian,

Am 19.06.2012 um 16:12 schrieb Florian Apolloner:

> 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…).

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.

Cheers,
Stephan

[Greg Aker]

Florian:

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?

Thanks,

-greg

[Andrew Godwin]

On 19/06/12 15:25, Stephan Jaensch wrote:
> Hi Florian,
>
> Am 19.06.2012 um 16:12 schrieb Florian Apolloner:
>
>> 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�).

>
> 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.

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.

Andrew

[Andrew Godwin]

On 19/06/12 16:13, Greg Aker wrote:
> Florian:
>
> 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?

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.

Andrew

[Greg Aker]

Good to know about native migrations, and the interim solution seems reasonable.

Thanks so much!

[Shai Berger]

Hi all,

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.

Have fun,
Shai.