[geeklog-devel] Draft of schema for GL2

[Vincent Furia]

> 2) I added a plugin_id to the action table, only outstanding issue is
> how are we representing kernel events?
I'd suggest making the core a pseudo plugin (i.e. it has an entry in
the plugin database probably with plugin_id value of 0).  We could
label it either "core" or "geeklog" or "GL2".  That would provide a
good way for the core gl2 to trigger and (potentially) listen for
plugin events...errr...I mean actions.

> 3) Versions can't be floats if they have two decimal points can they?  I
> think the validation on this needs to happen via the save's validation
> logic and I think we need to standardize that all version numbers are in
> the format x.y.z
Yeah, we can get the geeklog2 core to enforce this with whatever rules
we want.  We could even get fancy and store the plugin code state
(i.e. alpha, beta, gamma) as either part of the version or in another
DB field or even just kept a constant/variable in the plugin.

> 4) I didn't do anything with count fields...that's pending further
> discussion
Yup, I'd like to hear Dwight's input on that along with comments from
the people who had been/are experiencing the locking problem.

> 5) The supplemental user stuff was added to the gl2_user table
But you forgot to trash the supplemental user table. :)

> 7) I didn't see any datastructures related to preoder traversal stuff in
> categories.  I looked in the latest mysql_tables_and_data.php file on
> the comments table and didn't see a field that looked like what I was
> expecting.  What am I missing, Vinny?
You want the "lft" and "rht" columns from the comment table.  Try
reading this article I wrote about whats going on (I wouldn't mind a
critique on the article either...):
http://vinny.furiafamily.com/article.php?story=20041129154258296

Additional comments: I think we should trash the "logical_name" vs.
"display_name" in the group table.  The only group that should be hard
coded into the code is the Root group (where members of that groups
have rights everywhere).  All other access/privileges should be based
on ACLs and privileges.  If you really want other hard coded groups we
can handle "display names" by passing the group names through the
translator.  After saying all that I'd like to see logical_name and
display_name both be replaced by a single name column.

Tony said:
> Putting the catalogs in the list of values makes sense.
So the catalog table needs to be trashed and the category table
reflect that those values are in the list of values table (still
trying to come with a better name for that).

Tony said:
> gl2_action is fine by me.  However, just as we have namespace issues in
> the code with class names we could have similar issues with table names
> between plugins. I think we should try to address this with some sort of
> standard, if possible.
Tables for a plugin should be prefixed by the GL2 prefix followed by a
plugin specific prefix (probably the plugin's name).  That should do
it I'd think.

Tony said:
> I lump this in with the same issue with the ban plugin.  It's a basic
> decision as to what should be considered part of the kernel versus
> something that isn't.  I think this begs the need for a basic set of
> criteria that we agree on that should help us determine if something
> should be a plugin or in the kernel code.
I could go either way with comments (ratings I'd lean more toward a
plugin, but I wouldn't have a fit if it was in the core).  In any
case, we should establish those criteria you mention now before we get
too far into coding.

Tony said:
> What I was trying to achieve here is a plugin would insert a new set of
> item types (1 or more).  Each type can have their own set of states as
> this allows for customized work-ish tasks that are item-type specific.
> So to answer your question, yes, the plugin would insert their data, we
> are simply providing the structures.
I think we should drop the state_id since the core has nothing to do
with it and there is no guarantee (or even likelihood?) that all item
types will need it.  It's easy enough for plugin developers to put
that in there "plugin specific item table" which by our design would
have a 1-1 relationship with the item table.

I think that's enough for now.  I don't want to overwhelm Tony too much. :)
-Vinny