On Sun, 2006-07-09 at 05:37 +0000, Chris L wrote:
[...]
> Each row in the RLP(Row Level Permission) table contains:
> - The RLP id
> - The content type for the "owner" (e.g. user, group)
> - The id of the owner
> - The content type of the object
> - The id of the object
> - The permission id
> - If the RLP is negative or positive (e.g. user A can edit article 2 or
> user A can NOT edit article 2)
>
> No modifications of the permissions table at all. Trying to keep the
> current permission system the way it is, so if you don't want to use
> RLP, no need to make any changes.
No modification to the original model either, which is more what I was
asking about. Nice.
>
> > In case you were wondering (or it occurs to you later), one thing you
> > can't do here is call loading.get_model('auth', 'rowlevelpersmission')
> > -- which is what we do in some places. Because there is no guarantee
> > that the model cache is fully initialised at that point and it is wrong
> > (trust me!) to initialise the model cache inside get_model(). And you
> > can't import RowLevelPermissions at the head of base.py because, I
> > suspect, it will cause problems when trying to run ModelBase.__new__()
> > on itself.
>
> This could explain some problems I've been running into. Do you think
> my current location for importing the RLP ok?
It looks okay and you are protecting with a conditional test that checks
for the right attribute being present. What problems are you seeing?
It's pretty easy to get into a knot in the __new__() method there, but
from the fragment you posted you seem to have avoided the obvious
problems.
Just be aware (I guess you already are) that __new__() is run at import
time, not when you first create the model. And creating models with
relations to other models normally results in importing every model from
every installed app you have (because of some features in the Options
class implementation). I wrote up a somewhat detailed description of how
all this works in the wiki --
http://code.djangoproject.com/wiki/DevModelCreation -- which may be of
use if you haven't already worked out what is going on.
Difficult to guess what is happening without some details, but feel free
to post those if you are really stuck.
>
> > What I'm not sure I understand is how does the checking process work: if
> > I am trying to extract a particular instance from the database, does it
> > look up the row table for that content type, see if there's a matching
> > value for the primary key from my main model and then do the check?
> >
> > If so, that's at least one extra database query per extraction (I think
> > it might be two extras at the moment, but we can cache the content-type
> > with something like ticket #1717, although that will have to wait until
> > Adrian's finished playing inside django.db.models now). So, personally,
> > I would prefer it to be something that isn't on by default.
>
> It would have to look up the content type and use the content type and
> object id to determine the row level permissions that exist, or from
> another angle, the owner content type and the owner id. Never even
> thought about the extra database queries required. I think that's
> another good argument to have it disabled by default.
Just to be clear: looking up the content type is what ticket #1717 is
designed to optimise. It will cache the value after looking it up once.
It is, after all, a property of the model, not a property of each
instance of the model, so we can do it once quite safely. The only
reason it hasn't been committed yet is that I've been an old woman when
it comes to making a commitment on the API. I should just make a
decision (or hope that somebody else will!). So that query should be
essentially zero cost over the lifetime of a model. The other query to
determine the permissions is the one I was thinking about.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
