[development] module-specific columns in core tables

[David Strauss]

Use {node_revisions}.

Walt Daniels wrote:
> 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
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20070605/0f2e4183/attachment.pgp