List:General Discussion« Previous MessageNext Message »
From:Yves Goergen Date:February 11 2008 9:39pm
Subject:Re: Inefficient query processing?
View as plain text  
On 11.02.2008 20:13 CE(S)T, Peter Brawley wrote:
> If user.additionalkeylist and tag.readaccesskeylist are not lists, 
> naming them `...list` misleads & distracts.

Well, these fields contain KeylistId values from the "keylist" table, so 
I thought naming them *Keylist would be good enough.

> But on (i), how user.additionalkeylist and tag.readaccesskeylist work 
> remains confusing. You appear to say access may come from ...
> (i) message->message_revision->message_revision_tag.readaccesskeylist, or
> (ii) message_revision->user.additionalkeylist
> which implies there are positive values which provide access, but your 
> original query used the condition
> 
>     readaccesskeylist /is not null/
> 
> as a test for access /refusal/, which seems to contradict what you now say.

message.ReadAccessKeylist and message.SearchRevision-> 
message_revision_tag.ReadAccessKeylist are a list of keys of which *one* 
is required to get in.

user.AdditionalKeylist is a list of keys that the user possesses and of 
which *one* can be used to get in.

One list contains the keys that can be used, the other two lists contain 
keys that are allowed. One gives keys, the other accept keys. Imagine it 
like the user coming along with a keyring, trying to open a door with 
multiple keyholes. One of his keys must fit in one of the keyholes to 
get in.

And the problem here is that I need to test whether there is not a 
single tag for a (known) revision of a message that has an associated 
keylist to which no keys of the session user fits. If there was such a 
tag, access would be denied. To grant access, there must only be tags 
that either have ReadAccessKeylist IS NULL or that contain a key to 
which one of the session user's additional keys fits.

I'm still wondering if there's a way to explain all this better with 
some graphics.

-- 
Yves Goergen "LonelyPixel" <nospam.list@stripped>
Visit my web laboratory at http://beta.unclassified.de
Thread
Inefficient query processing?Yves Goergen10 Feb
  • Re: Inefficient query processing?Peter Brawley11 Feb
    • Re: Inefficient query processing?Yves Goergen11 Feb
      • Re: Inefficient query processing?Peter Brawley11 Feb
        • Re: Inefficient query processing?Yves Goergen11 Feb
          • Re: Inefficient query processing?Peter Brawley11 Feb
            • Re: Inefficient query processing?Yves Goergen11 Feb
              • Re: Inefficient query processing?Peter Brawley11 Feb
                • Re: Inefficient query processing?Yves Goergen11 Feb
  • Re: Inefficient query processing?Perrin Harkins11 Feb
    • Re: Inefficient query processing?Yves Goergen11 Feb
      • Re: Inefficient query processing?Perrin Harkins11 Feb
      • Re: Inefficient query processing?Peter Brawley11 Feb