[development] One-to-one tables considered harmful

[Moshe Weitzman]

I'll just add that the users module has explicit support for adding 
custom columns to it. those columns get magically loaded into user 
object and saved into the DB. please don't confuse this fine feature 
with the the horrid users.data column. i am speaking of new dedicated 
columns, not an existing column which is a catch-all.

so a similar feature for nodes is consistent and proper IMO.

Earl Miles wrote:
> David Strauss wrote:
>> Earl Miles wrote:
>>> At one point we had a 'field' op to nodeapi that let modules add fields
>>> to the node table. I would like to see this restored. Then we could
>>> justify never ever having a 1::1 relationship table for 'node'. This was
>>> taken out when the node_revisions table was added.
>>
>> Content types adding tables with 1::1 relationships to {node_revisions}
>> aren't a problem unless we use fields from the content type's table in
>> WHERE or ORDER BY criteria. I'm not aware of that happening anywhere in
>> core.
> 
> Ahh, but I bring this up for things like gsitemap or things that add 
> flags to nodes that will get queried by that module. Possibly with 
> queries similar to the tracker query. Some of these may be important.
> 
> If we had a 'kosher', acceptable way for a module to add fields to the 
> node table, and comment.module in core used that as a shining example, 
> then any and all of my objections to this on principle would vanish, 
> melt, disappear and be gone. And we'd get useful functionality, to boot.
> 
> I'd quickly turn out a 'node flags' module that let the administrator 
> create set arbitrary flags on a module, control who can set them, and 
> offer those flags up to Views, if the 'field' op for nodeapi were restored.
> 
>> That said, the current relationship between {node} and {node_revisions}
>> isn't too bad. We tend to not put WHERE or ORDER BY criteria on
>> {node_revisions} when joining.
> 
> Fair enough, that's a moot point then.
> 
>