[geeklog-devel] Draft of schema for GL2
tony at tonybibbs.com
Thu Dec 16 14:13:01 EST 2004
Vincent Furia wrote:
>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.
>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.
>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.
/me waits for Dwight
>But you forgot to trash the supplemental user table. :)
Oops.. I'll remove it.
>>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...):
No comments at this time. I was wondering WTF those columns were for.
Can we come up with a more descriptive name for them in the GL2 schema?
In the meantime I'll be considering this versus other search tree
>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.
Not sure I agree. We similar logic in the 1.3.x code with respect to
the inGroup() method. If you get rid of the logical name then you are
also saying to get rid of the inGroup() method all together. Is that
what you really want? Just want to be sure before we run off and remove it.
>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).
Yeah. I'll make remaining fixes.
>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.
K, so you'll add this to the start of the coding standards we have?
>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.
Ok, let me think about the criteria some and I'll post a new thread to
the list on this.
>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.
Think of it this way. Two states at the very minimum would be 'awaiting
approval' and 'approved' (or something to that effect). This would
essentially mimick the submission queues we have in 1.3.x today. I'm OK
with dropping this and going the plugin specific route but wanted to
make sure that we really don't think this is a must have feature.
>I think that's enough for now. I don't want to overwhelm Tony too much. :)
Tag, you (and Dwight) are it.
More information about the geeklog-devel