Gerhard Killesreiter wrote:
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'd be in favor of something along these lines:
node_flag('moderate') -- returns the name of the flag used for 'moderate' or NULL if there isn't one. node_flag_register('moderate') -- register the flag during .install, returns the real fieldname. Returns NULL if no flags are available. node_flag_list() -- return an array of all existing flags Modules can then register their flags which are directly put in the node table. We can pick some number of these; we could add a method to add more flags; Queries simply use node_flag('moderate') instead of 'moderate' if they care about it. They never need to know the field's true name. Cons: database names won't be transparent because it will just be 'flag1', 'flag2' or whatever, and some kind of translation may need to be done for things that look at a node as a whole. Also, 'flag1' on one Drupal install will have a completely different meaning from 'flag1' on another. I think both of these cons are quite minor; they allow us to kind of do away with the moderate flag without actually doing away with it. Modules which need to set flags can.