[geeklog-devtalk] geeklog-devel digest, Vol 1 #456 - 8 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Draft of schema for GL2 (dwight at trumbower.com)
   2. Re: Draft of schema for GL2 (Vincent Furia)
   3. Re: Draft of schema for GL2 (Tony Bibbs)
   4. Re: Draft of schema for GL2 (Tony Bibbs)
   5. Re: Draft of schema for GL2 (Vincent Furia)
   6. Re: Draft of schema for GL2 (Tony Bibbs)
   7. Re: Draft of schema for GL2 (Vincent Furia)
   8. Re: Draft of schema for GL2 (dwight at trumbower.com)

--__--__--

Message: 1
Date: Thu, 16 Dec 2004 13:00:25 -0500 (EST)
Subject: Re: [geeklog-devel] Draft of schema for GL2
From: dwight at trumbower.com
To: geeklog-devel at lists.geeklog.net
Reply-To: geeklog-devel at lists.geeklog.net


> I think we have to require INNODB.  Without it you don't get foreign

> keys nor transaction support.  Two things, IMHO, I don't want to live

> without.  I think eventually ISP's will get their act together and start

> supporting versions of MySQL that support INNODB (why that wouldn't be

> the default table type moving forward is beyond me).

>


Moving to INNODB is moving closer to a real DBMS and requires more
administration. For one, you can't do backups unless you take the database
off line or spend $500 for a product. I don't see ISP switching. Most
can't handle standard mysql properly.

I found this out when Dirk started making GL 1.3.x default to innodb. He
changed it back to myisam with an option to make it innodb.


I don't have a problem with forcing INNODB, just bringing up issues as I
see them. The target user for GL2 will be much smaller than it is today.

Dwight

--__--__--

Message: 2
Date: Thu, 16 Dec 2004 13:08:33 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net


> 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

--__--__--

Message: 3
Date: Thu, 16 Dec 2004 13:13:01 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net

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.

>  

>

That's fine.


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

>  

>

Sounds good


>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...):

>http://vinny.furiafamily.com/article.php?story=20041129154258296

>

>  

>

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


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

--Tony

--__--__--

Message: 4
Date: Thu, 16 Dec 2004 13:24:54 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net

I think we are fine.  Why?  Well, if we develop this using foreign keys 
I think we cover our arses in the case someone doesn't use INNODB.  
That's because I'm pretty sure that if a MySQL Server that doesn't have 
INNODB support compiled in and somenoe imports DDL for a database that 
tries to use INNODB, it will simply convert them to MyISAM and ignore 
any FOREIGN KEY constraints (as opposed to creating an error and dying).

As I said, the Propel classes enforce foreign key constraints natively 
(assuming the schema.xml is right) so in the MyISAM case we are still 
covered.  Only exception to this is obviously GL2 programmers can issue 
raw SQL so there is the possiblity of orphaned children.  But again, if 
all developers use INNODB the database during coding, we would catch any 
potential errors regardless.

So, in short, I don't think MyISAM users will be effected.  Of course 
someone will need to test this...

If I am right (which I'm pretty sure I am), we will want to put a stern 
warning about the possible effects of not using INNODB.  Also, this make 
the table-locking issue more complicated since we have to cover the 
MyISAM side of things as well.  Or does it?  Table locking should only 
occur on high traffic sites and, IMHO, you get what you get for using 
MyISAM on a wildly popular website.

--Tony

dwight at trumbower.com wrote:


> Moving to INNODB is moving closer to a real DBMS and requires more

>

>administration. For one, you can't do backups unless you take the database

>off line or spend $500 for a product. I don't see ISP switching. Most

>can't handle standard mysql properly.

>

>I found this out when Dirk started making GL 1.3.x default to innodb. He

>changed it back to myisam with an option to make it innodb.

>

>

>I don't have a problem with forcing INNODB, just bringing up issues as I

>see them. The target user for GL2 will be much smaller than it is today.

>

>Dwight

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>  

>



--__--__--

Message: 5
Date: Thu, 16 Dec 2004 14:31:36 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net


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

Yes.  If you look in the geeklog code for calls to SEC_inGroup() it is
really only used for the  Root group.  Most of the other instance
where it is used it is used against a group id variable.  The
remainder I would argue are redundant if we better respected
privileges in 1.3.x.  I'd recommend a "isRoot" function, but I think
"inGroup" is really not needed except when actually administering
group membership.


> 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

> implementations.

Better names for those columns wouldn't hurt, I just couldn't come up
with anything better when I was implementing it in 1.3.x.  I looked
around at other algorithms when I was first looking into improving the
performance of comments and didn't find anything better.  If you do
find something let me know.  This was, by far, the best I found.  The
biggest downside is that I had to lock the table during inserts, but
that is really OBE since we can use transactions.

-Vinny

--__--__--

Message: 6
Date: Thu, 16 Dec 2004 13:35:07 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net

Vincent Furia wrote:


>Yes.  If you look in the geeklog code for calls to SEC_inGroup() it is

>really only used for the  Root group.  Most of the other instance

>where it is used it is used against a group id variable.  The

>remainder I would argue are redundant if we better respected

>privileges in 1.3.x.  I'd recommend a "isRoot" function, but I think

>"inGroup" is really not needed except when actually administering

>group membership.

>  

>

Ok, I say we yank it...adding that column in if deemed appropriate isn't 
too hard.


>Better names for those columns wouldn't hurt, I just couldn't come up

>with anything better when I was implementing it in 1.3.x.  I looked

>around at other algorithms when I was first looking into improving the

>performance of comments and didn't find anything better.  If you do

>find something let me know.  This was, by far, the best I found.  The

>biggest downside is that I had to lock the table during inserts, but

>that is really OBE since we can use transactions.

>  

>

Was this an original implementation or was it one you borrowed from 
someplace?  WTF does slashcode use...you'd think they'd have to have 
this issue nailed down by now.

--Tony

--__--__--

Message: 7
Date: Thu, 16 Dec 2004 14:46:04 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net

I didn't look at slashcode.  But most other CMSs I looked at just grab
all the comments from the DB and use a recursive php algorithm.  I
didn't see any that had an efficient (or smart) way of grabbing
comments.

The implementation is original, the algorithm was spelled out in a
couple different places with slight variations in the details.

-Vinny


On Thu, 16 Dec 2004 13:35:07 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> Vincent Furia wrote:

> 

> >Yes.  If you look in the geeklog code for calls to SEC_inGroup() it is

> >really only used for the  Root group.  Most of the other instance

> >where it is used it is used against a group id variable.  The

> >remainder I would argue are redundant if we better respected

> >privileges in 1.3.x.  I'd recommend a "isRoot" function, but I think

> >"inGroup" is really not needed except when actually administering

> >group membership.

> >

> >

> Ok, I say we yank it...adding that column in if deemed appropriate isn't

> too hard.

> 

> >Better names for those columns wouldn't hurt, I just couldn't come up

> >with anything better when I was implementing it in 1.3.x.  I looked

> >around at other algorithms when I was first looking into improving the

> >performance of comments and didn't find anything better.  If you do

> >find something let me know.  This was, by far, the best I found.  The

> >biggest downside is that I had to lock the table during inserts, but

> >that is really OBE since we can use transactions.

> >

> >

> Was this an original implementation or was it one you borrowed from

> someplace?  WTF does slashcode use...you'd think they'd have to have

> this issue nailed down by now.

> 

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 8
Date: Thu, 16 Dec 2004 14:49:55 -0500 (EST)
Subject: Re: [geeklog-devel] Draft of schema for GL2
From: dwight at trumbower.com
To: geeklog-devel at lists.geeklog.net
Reply-To: geeklog-devel at lists.geeklog.net

We are fine as long as you don't use foreign key specific functions. LIke
Cascade deletes and updates. Which it sounds like Propel will handle this.
myisam will just ignore the ddl for foreign keys.

Dwight


>From MySql:

In MySQL Server 3.23.44 and up, the InnoDB storage engine supports
checking of foreign key constraints, including CASCADE, ON DELETE, and ON
UPDATE. See section 15.7.4 FOREIGN KEY Constraints.

For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY
syntax in CREATE TABLE statements, but does not use or store it. In the
future, the implementation will be extended to store this information in
the table specification file so that it may be retrieved by mysqldump and
ODBC. At a later stage, foreign key constraints will be implemented for
MyISAM tables as well.





> I think we are fine.  Why?  Well, if we develop this using foreign keys

> I think we cover our arses in the case someone doesn't use INNODB.

> That's because I'm pretty sure that if a MySQL Server that doesn't have

> INNODB support compiled in and somenoe imports DDL for a database that

> tries to use INNODB, it will simply convert them to MyISAM and ignore

> any FOREIGN KEY constraints (as opposed to creating an error and dying).

>

> As I said, the Propel classes enforce foreign key constraints natively

> (assuming the schema.xml is right) so in the MyISAM case we are still

> covered.  Only exception to this is obviously GL2 programmers can issue

> raw SQL so there is the possiblity of orphaned children.  But again, if

> all developers use INNODB the database during coding, we would catch any

> potential errors regardless.

>

> So, in short, I don't think MyISAM users will be effected.  Of course

> someone will need to test this...

>

> If I am right (which I'm pretty sure I am), we will want to put a stern

> warning about the possible effects of not using INNODB.  Also, this make

> the table-locking issue more complicated since we have to cover the

> MyISAM side of things as well.  Or does it?  Table locking should only

> occur on high traffic sites and, IMHO, you get what you get for using

> MyISAM on a wildly popular website.

>

> --Tony

>

> dwight at trumbower.com wrote:

>

>> Moving to INNODB is moving closer to a real DBMS and requires more

>>

>>administration. For one, you can't do backups unless you take the

>> database

>>off line or spend $500 for a product. I don't see ISP switching. Most

>>can't handle standard mysql properly.

>>

>>I found this out when Dirk started making GL 1.3.x default to innodb. He

>>changed it back to myisam with an option to make it innodb.

>>

>>

>>I don't have a problem with forcing INNODB, just bringing up issues as I

>>see them. The target user for GL2 will be much smaller than it is today.

>>

>>Dwight

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

>>

>>

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>




--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest