Re: Houston, we have a problem...

[Jason Pincin <chardros@linuxkb.org>]

Nope.  I've already considered that.  Believe me... I've considered MANY
different ways to handle object location... they all have they're ups &
downs.

Tracking object location by "parent only" is nice for re-categorization.
Where it SUCKS is security.

I went back and forth for this for a long time.  The root of the problem
is that we're implimenting the LinuxKb as script that loads, executes, and
unloads.  So what I decided is that, in the long term we will ideally
reach location tracking by parent id only, but for now, we must track the
entire location of an object.  Here's why:

Say I have a category called DNS, and under there I have two applications,
once called named, and the other called nslookup.  under each of those
applications are several articles.  Now, I want to assign someone as a
"moderator" for the "DNS" category, and I want them to hav certain
privleges over ALL articles, categories, etc under that DNS category.  To
do this I have 2 options... I can either assign the permissions ONCE, to
the DNS category and mark it as a recursive permission, or I can assign
the SAME permission to EVERY object beneath that category.  So I thought,
well, if I enable recursive permissions, I'm going to save a helluva lot
of space in the permissions DB, which in turn will allow for much quicker
access to user/object security info which will be needed on nearly every
page load.  Thats a good thing methinks.  Plus, it reduced the chance of
page bugs screwing up and missing some permission re-assignments etc.  So
I took the approach of enabling recursive permissions.

Now... In order to do that, you need to know all the parents of an object
in order to scan for any recursive permissions set on parents.  To do this
when only tracking parent ID's of objects would involve monster/multiple
slow queries.  You'd have to query the first parent, find out what it's
parent was, then query that parent for it's parent, etc. all the way up
the line until there were no more parents.  The deeper you drilled the
more massive the permissions query would become.  I thought this was bad.
In order to correct this problem, each object had to store it's entire
heritage.  This makes the permissions scan small and quick no matter how
deep you go, but complicates re-organization.  

I figured, permissions scans would be happening on nearly every page load,
and re-organization's would be once-and-done type queries... so I opted
for the approach you see before you.

This will be a total pain in the ass to re-organize at the sql cmd-line
level, but the admin pages can handle it very easily.

And re-organizations will not affect permissions at all since permissions
are stored by object id, not object location.

The only other option for this would be to store location via parent
object id, and have object locations updated via DB triggers, but MySQL
does not support triggers, so we're screwed there as well.

Thoughts/Comments/Suggestions welcome.

Jason



On Wed, Dec 29, 1999 at 11:37:47AM -0800, Aaron Turner wrote:
> 
> I just found a "problem".  It's more of an annoyance really.  Take this
> example- you have two parent categories:
> 
> 1.3 Networking
> 1.42 Sys_Admin
> 
> I decide I want to move the Networking category under Sys_Admin:
> 
> 1.42.3 Networking
> 
> Easy enough.  Except that all the categories/articles under Networking:
> 
> 1.3.5 DNS
> 1.3.23 PPP
> 
> No longer exist on the web site.  They're kinda like orphaned children
> because the parent left them.  This means that if we ever move a category,
> we have to find all the old children and move them manually one by one.  A
> far better solution is to store cats/arts in the db not by specifying the
> whole location, but just the parent ID.  This way you can move the parent
> and all the children automatically follow it.
> 
> As far as I can tell, this is just a matter of fixing functions.php3 to
> work with the DB in a slightly different manner.  Probably a significant
> bit of work though.
> 
> Comments?
> 
> --
> Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
> Linux Knowledge Base Organization  http://linuxkb.org/
> Because world domination requires quality open documentation.
> aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net

-- 
Jason
http://vodka.linuxkb.org/~chardros