[development] module-specific columns in core tables

[John Wilkins]

On Jun 5, 2007, at 10:36 AM, 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.

And, as Gabor said, we would need to carefully make sure the upgrade  
of this modified table was handled sanely.

Perhaps, a db schema API for table deletion/upgrade that allows  
modules to handle it's own columns.  That's an EXTREMELY rough idea,  
but I'm sure there are smarter people who could shape it into  
something useful.

I hope no one minds that I moved this to a new thread.