[development] Moderation bit behavior
gerhard at killesreiter.de
Wed Jul 5 15:41:58 UTC 2006
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
> 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.
More information about the development