Permission Duplication

[Valentin Golev]

Hello!

Two things, specific and more abstract:

1. I've run into something that seems like a bug. If it really is a bug, I'll file a ticket, if it's not, please clarify the behaviour, and, in this case, I think a better error message will be awesome.

Basically, if there are two permissions for a model with same codenames and different descriptions, Django tries to add both in the database, but there is a unique index on codename so it all crashes horribly.

The code which is responsible for this is at create_permissions() function[1]. There is a set: `searched_perms`, so it should help to avoid duplicate values. But the second element of every tuple in set, namely "perm", is another tuple of (codename, name), and the "name" is a human-readable name and not an identifier. So if we have two permissions with same codenames, but different "name"s, set will see them as different permissions and django will try to insert them both in the database. However, the unique index is only on two fields: ctype and codename, so permissions with same ctype and codename, but different "names", can't be inserted. That results in a pretty odd stacktrace[2]. Please ignore that it is from South, I'm pretty sure it has nothing to do with all of this mess. I never tried, though.

The simple case with duplicate permissions is adding a "change_thingy" permission to your model. Even if one forgets about this permission already added by Django, he doesn't deserver suffering and using pdb to understand what's going on :-)

So, please, let's decide if it's a bug in behavior or a bug in error-reporting and solve it!

2. Another idea being in my head lately is that since there is a better logging support in django nowadays, maybe it's time to try adding a dozen of warnings and suggestions to humble Django users. I'd like to try to improve overall error-reporting and in Django. Several ideas from the top of my head:

* Handling apps with no "models.py". It seems like Django silences this error and removes the app from the app list. It doesn't play nice with several things, like testing. I think there should be a warning in runserver's console.

* I think there should be ready to use runserver-console handler for logging (seems like just a normal StreamHandler), and it could be enabled by default in settings.py

* I also think there should be some interesting logging namespaces, like django.db.query for logging all queries.

* An awesome feature will be helping with solving O(n) queries errors (and other database mistakes) - gentle warnings in console when two almost same queries are running during the same request. It doesn't seem like a simple task to do, but definitely like an interesting one.

Sorry if some of these is already in Django or in the bug tracker.


[1]: http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/management/__init__.py#L19

[2]: https://gist.github.com/945736

[Carl Meyer]

Hi Valentin,

On 04/27/2011 10:33 PM, Valentin Golev wrote:
> 1. I've run into something that seems like a bug. If it really is a bug,
> I'll file a ticket, if it's not, please clarify the behaviour, and, in
> this case, I think a better error message will be awesome.
>
> Basically, if there are two permissions for a model with same codenames
> and different descriptions, Django tries to add both in the database,
> but there is a unique index on codename so it all crashes horribly.

This sounds like a bug to me - Django should detect the duplicate
codename and give a reasonable error before trying to save it to the
database. Please do file a bug (if there isn't one already).

> 2. Another idea being in my head lately is that since there is a better
> logging support in django nowadays, maybe it's time to try adding a
> dozen of warnings and suggestions to humble Django users. I'd like to
> try to improve overall error-reporting and in Django. Several ideas from
> the top of my head:
>
> * Handling apps with no "models.py". It seems like Django silences this
> error and removes the app from the app list. It doesn't play nice with
> several things, like testing. I think there should be a warning in
> runserver's console.

I agree that we could do something better here. The first thing I'd want
to check is how this is handled in the app-loading branch that Jannis
Leidel and Arthur Koziel are currently working on, from Arthur's GSoC
work last summer. That will hopefully be merged soon, and will change a
fair bit of behavior around model-loading and INSTALLED_APPS.

> * I think there should be ready to use runserver-console handler for
> logging (seems like just a normal StreamHandler), and it could be
> enabled by default in settings.py

This sounds to me worth filing a ticket for, if there isn't one already.
I'm not sure about enabling it by default, but perhaps with a flag to
runserver.

> * I also think there should be some interesting logging namespaces, like
> django.db.query for logging all queries.

My understanding is that there's a general intention to do more useful
logging now that the logging framework is in place, so I think specific
tickets and patches in this area would be welcome.

> * An awesome feature will be helping with solving O(n) queries errors
> (and other database mistakes) - gentle warnings in console when two
> almost same queries are running during the same request. It doesn't seem
> like a simple task to do, but definitely like an interesting one.

My immediate reaction is that we don't need to get this tricky; just
making it easier to log queries and see that log in console will greatly
improve immediate awareness of O(n) query situations.

Carl

[Valentin Golev]

Created two tickets.

http://code.djangoproject.com/ticket/15915
http://code.djangoproject.com/ticket/15916

The latter seems a bit vague to me. I'm thinking about creating some
specific tickets and patches to provide better console experience :-)

If it's a noble goal, and there weren't huge discussions on it, let's
think about how to make django more verbose, polite and useful using
logging framework

--
Valya Golev

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>