[development] Moderation bit behavior

[Gerhard Killesreiter]

Mark Fredrickson wrote:
> On the subject of bits on nodes, I would advocate for the least number 
> of hard wired fields as possible. Hardwired data conflicts with user 
> configurable systems and makes administration harder and more confusing 
> for end users. Instead, I would advocate for dynamically added data 
> (from modules) where needed.
> 
> In more specific terms, let me argue for removing a large portion of the 
> current node object (feel free to disagree):
> 
>  From the node table:
> nid  - keep
> vid  - keep
> type  - keep
> title  - remove. Titles should be set by node modules (and stored where 
> the body and teaser are), not stored in the node table.


This was a design decision. We often only need the title of a node (for 
link lists for example). If we do a join on the node_revisions table, we 
lose a lot of time. We are contemplating to add the author's name for 
the same reason (save join on user table).

> uid   - keep
> status  - remove. Let a module like workflow control the state of the 
> node. Or, don't have a state. Let the admin decide. Node_access is a 
> better solution than an all or nothing published state, in my opinion.
> created - keep.
> changed - keep
> comment - remove. Why would I want this data if I don't allow comments? 
> Spareness should be avoided if we can help it.
> promote - remove. Let's move nodequeue into core and make a default 
> "front page" queue. This more extensible.
> moderate - remove. As this thread shows, no one is sure exactly what 
> moderate should do. Let a moderation system control node moderation.
> sticky - remove. Again, let the nodequeue system decide what is first in 
> the order.

I'd be in favour of a more flexible bitfield instead of all the single 
fields.


> I would also like to see us move away from body and teaser fields in the 
> node_revisions table. If I only use CCK nodes in my site, these fields 
> will be useless for every single node I have.

Then they'll be empty and won't hurt.

> If we do move towards an 
> "everything is a node" or at least "most things are a node" model, the 
> body and teaser fields will seem anachronistic.

Well, we don't know if we move there. Also, it would be convenient to 
store pre-rendered html there...

> Yes, this position does require more joins. I understand there is a 
> penalty. I think that penalty is worth the simplicity and can be 
> overcome with better caching.

I am not sure. Getting caching right is a difficult thing and getting 
queries to perform better is much easier.

Cheers,
	Gerhard