Mark Fredrickson wrote:
Flame war aside, I think there are some good points in this thread. Perhaps someone can clarify two points:
1. Is it kosher to add columns to other modules' tables? E.g. Is it ok for comment to add it's statistics to the node table. Similarly, I could imagine the stats module would want to add summary information, and perhaps other modules as well.
The problem with dynamically modifying other module's tables has one glaring problem: the upgrade path. Now let's take menu module or locale module. Locale module had the locales_meta table in Drupal 5. If contrib modules added columns to this table, the column and the data will be completely lost, since the Drupal 6 upgrade creates a new "languages" table, gets the data **which is expected by locale module to be there** in the old locales_meta table and finally drops the locales_meta table. So only the data handled by the module will be saved. Similar issues can arise when data is updated only, if you would do updates in your custom columns in those algorithms too. Or the module update might try to add a column named as the one which was put there by some of your other modules. So as long as you modify someone else's (either core module or contrib, does not matter) table in a contrib module, you fork Drupal, and you are on your own to handle the situations that can possibly arise. Optimizing *core* functionality by putting related data together is a different question though.
2. Do David's arguments support more Single Table Inheritance[1] in Drupal (e.g. adding columns to node that don't necessarily apply to every node type)? For example, should CCK add columns to the node table that only apply to some types of nodes.
Hm, the node table already has a newly added column in Drupal 6 to store the language code, and this is not managed in node module. Dries also requested to add node translation related fields directly into the node table underlining that this is a core feature (even if you don't have the node translation module enabled). [Node translation is still in the works, look here: http://drupal.org/node/142280 ] I would not advise any contrib module to modify anyone else's core or contrib table, but feel free to play along with their own tables as they wish. I don't think it is a good idea maintanance wise for CCK to modify the node table directly, although it might look performance wise attractive. Gabor