Re: Proposal: User 'Everybody'

["Alexey Parshin" <alexeyp@gmail.com>]

I don't think that I can give you some numbers (like timing) at the moment. Not till we have any significant number of users (say - few hundred) and UMOs. Only then we can estimate the join time and the time of SELECT all the user ACLs into temp table, and compare them.

So, at this point - should I start converting schema now?

2007/4/16, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

Alexey Parshin wrote:
> What we are changing is at least:
>
> 1) Adding group_list table with groups.
> 2) Adding user_to_group table to include user into group
> 3) Changing ACLs from referring to person_list to referring to group_list
>
> The most concern is that instead of simple query to get an ACL like:
>
> SELECT tla_access FROM topic_list_acl
> WHERE tla_person = ? and tla_topic = ?
>
> we would have:
>
> SELECT tla_access FROM topic_list_acl, user_to_group
> WHERE
>     utg_group = tla_group AND utg_person = ?
>     AND tla_topic = ?
>
> Of course, I may make a compound index on (utg_group,utg_person) but
> we still have a join never the less.
>
> Creating a temp table with materialized view of ACLs for that user
> would speed it up, IF we have persistent connection that is controlled
> by the session id. Otherwise - the generation of such temp table may
> slow us down. BUT, if we make this persistent connection, then we
> cannot change user's permission while that user is logged in :(
You know that connection-per-session is no-go.
Now, temp table with only user's groups will speed things up -
if we have to do more then one permission check per request.
Otherwise we'll have to live with joins like above, which, I agree,
sucks. However, these are implementation details, and they still
lack actual numbers. And I still didn't see anything that would
be bad from user's POV.
Another thing temp table may help with is special-casing some groups
(i.e. Everybody).

>
> 2007/4/16, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     Alexey Parshin wrote:
>     > I think, we're opening a can of worms here.
>     I'd like to hear specifics please :)
>     > Having group-level security slows us down, but what do we have as
>     > advantage?
>     Easier management.  Previously we didn't have any provisions for
>     differentiating
>     between groups of users of objects.
>     > I know how to implement it, it's just little bit strange.
>     What is strange about groups?
>     > So, if you really want it - I'd start changing schema.
>     I am still undecided. If you show me some real problems, I may change
>     my mind. If you can quantify performance impact, it'd help
>     decision-making
>     too.
>     > It also means that I'd have to redo most of the work done for
>     last two
>     > weeks :(
>     Well, things do not change _that_ much - we just replace users with
>     groups in
>     access checking procedures..
>     >
>     > 2007/4/16, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com>
>     > <mailto: ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com>>>:
>     >
>     >     Alexey Parshin wrote:
>     >     > I'm reading your e-mails. I just don't see the need to
>     work with
>     >     > single-user groups, at least - I'd prefer not to create such
>     >     groups as
>     >     > a part of user-creation process.
>     >     How do you grant access to individual users then? Create a
>     >     new single-user group every time it's needed?
>     >     > Also, creating a group 'Everybody' would probably simplify a
>     >     > permission search but it would also slow it down. I
>     propose to
>     >     create
>     >     > such group but don't include anyone in there - we can
>     simply assume
>     >     > all the users are there in our SQL.
>     >     So, you want to special-case it? Wouldn't that slow things down
>     >     just as
>     >     well?
>     >     Although.. I guess we could populate groups temp table with
>     group
>     >     Everybody,
>     >     without having data in permanent table.. Hmm.. I'll say -
>     your call..
>     >     >
>     >     > 2007/4/16, Ilya A. Volynets-Evenbakh
>     <ilya@total-knowledge.com <mailto:ilya@total-knowledge.com>
>     >     <mailto: ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com>>
>     >     > <mailto: ilya@total-knowledge.com
>     <mailto:ilya@total-knowledge.com>
>     >     <mailto:ilya@total-knowledge.com
>     <mailto: ilya@total-knowledge.com>>>>:
>     >     >
>     >     >     Man, aren't you reading my mails? ;-)
>     >     >     If you need to give access to single individual, you use
>     >     >     their personal group. This avoids having to search
>     through
>     >     >     two tables, thus making code simpler.
>     >     >
>     >     >     Alexey Parshin wrote:
>     >     >     > What's the idea behind a group per person?
>     >     >     >
>     >     >     >
>     >     >     > < http://www.sptk.net>
>     >     >
>     >     >     --
>     >     >     Ilya A. Volynets-Evenbakh
>     >     >     Total Knowledge. CTO
>     >     >     http://www.total-knowledge.com
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > --
>     >     > Alexey Parshin,
>     >     > http://www.sptk.net
>     >
>     >     --
>     >     Ilya A. Volynets-Evenbakh
>     >     Total Knowledge. CTO
>     >     http://www.total-knowledge.com <http://www.total-knowledge.com>
>     >
>     >
>     >
>     >
>     > --
>     > Alexey Parshin,
>     > http://www.sptk.net
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

-- 
Alexey Parshin,
http://www.sptk.net