term_data, term_image, term color

One very important rule of life in Drupal: "never change a core table." It can cause all kinds of problems - especially with upgrades. You could also then get into many inter-module collisions doing that. I've made these same arguments before and even tried a few core table changes only to have some of the reasons not to do so hit me hard. It is a bad practice.

For many of the same reasons, contrib developers don't modify each others' tables.

There are probably many tables in core that one could argue should be nodes (an I will join in the argument for users). But if one looks at, and understands, the node structure, one will see that this could complicate things immeasurably. The main problem is that a "node" has basically only two fields: title and body. So if you need more than two fields, then you have to create, manage, and query additional tables - probably adding to the complexity rather than saving it.

Yeah, you definitely don't want to alter the core taxonomy table for the reasons Nancy stated. What might be nice, though, is if the maintainers who are adding things to taxonomy got together and shared a table. That does add a level of complexity when uninstalling modules so that would have to be addressed, but it has the benefit of less tiny tables. With my work on advforum, I've been wanting to store extra information about each forum, which are taxonomy terms. So I was planning on making a table to hold that. Maybe getting together with you and the other maintainers would be better than adding yet another table just to store one field?

Michelle

As long as we can all work out a good strategy for managing the table(s), that's fine with me. On the other hand, tiny tables are fast to access.

Hmm... That's a good point. Would the quickness of small tables outweigh any con in having a lot of them? I don't know enough about databases to answer that. Might not be enough of a benefit to bother with trying to collaborate on tables. It was just a thought I had while answering this issue as requested. :)

Michelle

Okay, Peter, let's say we did something like this (and I'm not opposed to module synergy, and would like consistent coloring in Event), let's look at some scenarios:

1) Either module gets uninstalled, what do we do with the table?
2) A fundamental change to the taxonomy module (say for D7, which is now being developed) is made that allows one, but not both attributes to be moved directly into taxonomy.
3) Either module becomes unmaintained (TI was close to that before I asked for co-maintainer status).
4) Either module adds additional fields to the table, or worse still, new indexes (yes, that is possible right now with TI).

David Strauss is the main database guru for Drupal; here's what he said when I asked about doing something like this:
A single table is faster, but collaborating with other modules on (tid, xyz) tables is likely to encounter the same risks as adding columns to core tables.

'new indexes' - Do you mean database table indexes (in {term_data} or {term_image}?) or something in drupal php code?
I think a tid primary key index is enough for {term_image}(tid,path,color) satellite table. The need for 'ORDER BY' and 'JOIN' by path or color is very low. And they mustn't be UNIQUE.

For example, there is an open issue to allow multiple images for a term. I would envision that as requiring some type of sequence field, which would have to be added to tid to keep the index unique.

What did David Strauss mean with a 'single table'? A database table {term_data} that holds the additional fields -
or satellite tables of {term_data} with only 1 value field and the referencing tid field?

Satellite tables - he (and I) will never encourage changing a core table.

I'm trying to come up with an idea that will accomplish this idea and still be maintainable. It may require another module. For example a "Term Descriptions" module, which can provide a hook to other modules for adding fields (and indexes). It is still a very loose concept in my head. And, BTW, it would probably be only for 6.x, not 5.x.

@peterdd: have you seen http://drupal.org/project/taxonomy_enhancer?

Nancy: I'm new to drupal innards so this may be naive, but isn't "adding and deleting columns" a more general issue than just term image or term descriptions?

I imagine a facility which is called when a module wants to add or remove a column from a given table shared with other modules (eg: on installing, removing, or updating the module). Some field(s) would be described as a primary key. When the first fields are added, the table is created; when fields are added or removed, the table is altered. If the last non-key field is removed, the table is removed. Indexes can be added along with fields, and are removed with them.

If all non-key fields of a given record are null, the record can be removed (modules making use of this facility would be written to assume there's no need to store a record with all null fields).

Any module making use of these tables can check for which fields are defined, if it wants to make use of some field created by another module. (Or can conflate null entries in a field and undefined fields as the same meaning, if desired)

As I say, I'm new to this - for all I know, maybe that's how CCK is implemented (or something more sophisticated but similar). The idea of half a dozen modules creating their own new tables (all using the same key, eg: tid to link to terms) to store the same key and a new index, and add one or fields each doesn't appeal to me, somehow, performance wise.

Zeph

No, that's not how CCK is generally used, although there is some capability for reuse of fields.

The closest thing I've seen to what you are describing is the Taxonomy Enhancer module. I have had a look at it and it has some promise, but I think needs a more active maintainer and some idea people.

In a way, I agree that multiple tables with similar data is redundant. However, the maintenance issues are pretty significant, that's why it isn't being done (yet).

Taxonomy Image may participate in such a solution, if it is ever developed, but it is not something I am going to solve with TI.

Although the tables manipulation issues are indeed a morass, I think that the proposal for
- term colors and
- images managed as references to existing nodes
are good feature requests.

I certainly could use real integration with my existing icons and thumbnails rather than uploading repeats in different places. Especially as the client this week keeps changing the default 'thumbnail' size.

Dan, I don't disagree. What I do disagree with is that TI is the proper place to fix this. If lots of people want this, let's work with Taxonomy Enhancer (or something like that) to make it a viable and supported API.

http://drupal.org/node/231605

Dan and Michelle: I have recently been having a look at hook_schema_alter for a different module, that uses the "contrib" model that we also use on TI. This might well provide a viable solution to the "bolt on" idea. Have you any ideas in that area?

No, sorry. I'm not familiar with the hook and never did get around to adding anything along these lines to AF. Maybe in 2.x.

Michelle