[development] module-specific columns in core tables

[Walt Daniels]

For example I wish the node table had a last edited by user field as well as
the created by user field. In an enviroment where multiple people can modify
nodes it is more interesting to know the last modifier than the creator.
Yes, I know that can be gotten if you turn revisions on but I don't need
that functionality. 

-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of John Wilkins
Sent: Tuesday, June 05, 2007 1:48 PM
To: development at drupal.org
Subject: [development] module-specific columns in core tables


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.


--
No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.9/832 - Release Date: 6/4/2007 6:43
PM