Re: Houston, we have a problem...

[Jason Pincin <chardros@linuxkb.org>]

> > 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.
> I don't see why.  There's no need to do a permission scan for avg. joe
> user who is using the site.  Only category admins.

Because I'm thinking broader than just the KB.  Sure, in ouir enviroment,
most people will have "read" perms over everything... but I'm trying to
design this system so that it will eventually scale to other applications
as well.  In other apps, it may be necisary to check perms on
everything... and if it's done quickly, it doesn't impact us anyway...
and, it's already implimented so... if we go this way, we are targeting
other apps, it works for us, and we don't change anything.

> > 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.
> Are you say converting to my proposal will be difficult?  It would be VERY
> easy to do in Perl.  Maybe 20 lines of code, max.

No.  It wouldn't be overly difficult to make the modifications.  Assessing
the impact on the DB would be a different story.  I don't like the idea of
updating a permissions table of file 6 times a day like we're doing with
PHP Cache... permissions must be real time.

> > 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.
> ???  What's a trigger, and how would that help?  Just curious.

A DB that supports triggers has the ability to say... "Any time field X is
updated, update field Y in table Z to reflect the change in a given
manner"


Jason




> > > 
> > > 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
> > 
> 
> --
> 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