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.