Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | taxonomy.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
This is the first pass in an attempt to bring some sanity (and scalability) to taxonomy_get_tree(). And as a side-effect help fulfill a critical feature request from the EOL taxonomy sprint.
Multiple parents currently have a number of issues:
1. We expose them for data entry when selecting terms (although not in a nice way)
2. Once the parents have been added, they're not exposed anywhere in the user interface - unless they're breaking a contrib module's breadcrumb handling or something.
3. They mean that taxonomy_get_tree (and friends) have to do recursive queries.
4. They're buggy - see #144969: taxonomy_term_count_nodes returns wrong count (+ tests)
5. It makes re-factoring taxonomy hierarchy with either nested sets or materialised path 1000 times more complex
6. Hardly anyone uses it, and when they do, they often realise at a later date that they should have used two vocabularies instead
7. If you use them, drag and drop gets switched off.
No patch yet, I propose we move multiple parents out of the main term hierarchy into a term relationship.
This involves a couple of things:
Add a 'type' column to the term_relations table
At the EOL Taxnomy Sprint - one major feature request which came up was allowing for more rich metadata for terms and their relationships - so tid1 is 'a parasite of' tid2, tid1 is 'a predator of' tid2 etc. - adding the type column ought to be enough for contrib modules to then provide a UI for adding those types.
trid tid1 tid2 type (varchar)
The update path would first make all existing term relationships 'default'. Multiple parents from core would get inserted into this table as tid1 'has the parent' tid2. So to get the extra parents, you'd just do SELECT tid2 from term_relations WHERE tid1 = :tid AND type = 'parent'
This would then allow us to slap a unique index on term_hierarchy.tid - which paves the way for denormalising this information into a term_lineage table (or similar) - allowing for inexpensive queries for lineage and depth in a follow-up patch.
Comments
#1
+1 for optimizing the architecture, -1 for "Hardly anyone uses it, and when they do, they often realise at a later date that they should have used two vocabularies instead".
Geographical taxonomies are perfect candidates for multiple parent relationships, boy how many shared pieces of water or mountains are out there ;)
How "primary" parent - the one what will be stored to normal tid hierarchy -- gets decided from the UI perspective? Will the first one gets the prime seat and the rest will be dumped to relations?
A
#2
High Level Perspective
Use Case: We are currently moving our Infrastructure Repository at star-tides.net from D5 to D6 and have been looking for ways to develop the taxonomy support we need to support hierarchical taxonomy with multiple levels and a thesaurus. Our D5 solution was a custom module - Our D6 solution was headed the same direction but we are now looking at some of the solutions from the EOL Taxonomy Sprint http://groups.drupal.org/node/14749
Any solution that will help performance with recursion into N-level taxonomies and provide a means to customize sideways relationships between terms is welcomed. And I believe that would include moving multiple parents out of the hierarchy to a term relationship as it should allow for the flexibility we may need in our use case. E.g. Solar can be used for power, cooking, heating, water purification - direct and/or indirect in some cases.
Of course, hard to tell until trying to implement, but I do not see any downside here other than perhaps concern over upgrade path. Would upgrade path from D6 to D7 be via Taxidermy or only core to core?
#3
For those following along at home, drico (http://updates.drupal.org/user/25751) has been working on implementing http://arxiv.org/abs/0806.3115v1 (see the PDF link on right hand side).
The short version is it's a storage method for hierarchies which allows for both quick reads and writes - which potentially can handle all the structures our current taxonomy hierarchy structure does, without the nastiness. The main reason for removing multiple parents would be that all the other methods (variations on either nested sets like this one, or materialised path etc.) can only do fast reads OR fast writes - and have some other limitations depending on implementation, like sorting, or depth.
If it does everything it promises, then we could forget about this issue (but the basic relationship type handling might still be worth doing). However there's not yet working code or a patch yet - so I'm going to leave this open. Either way I think we can come up with something that would allow for Kika's use case but still simplify things a bit (not that the above document is simple, but the storage requirements are minimal and the actual functions would no longer need recursive lookups).
#4
Searching to insure Drupal 6 still (correctly) supported multi-parent terms, I found this node via Google Search[Drupal-6 OR D6 multi OR multiple parent term] and...
I concur: Please do not remove nor discontinue support for multiple parents!
As there are natural real & significant cases where a multi-parent term is appropriate.
Examples:
is a rhombus a parallelogram or an equilateral? Both! Indeed it is exactly the intersection.
the topic of "Drupal installation", so much we'd like to make vocabulary term for that. Well does that term fall under "Drupal" or "installation"? Again both! Indeed,
Drupal got it right with the fact that nodes need multi-tagging; and it's easy to see if we have several such nodes needing some same collection of tags/terms that being able to have just one multi-parent term to tag them all makes a lot of sense, too.
Indeed with some of this this in mind the Category Module was developed (and know any others?) except/as Category seems to've missed the boat in that it uses the Book Module to represent a term and it seems the Book node can only have one parent! (and the code's not finished: in alpha4, last mod 2008-Jul-21). Still, know or thinking of any developments here? (to Nodify Terms) I'd love to here & see more development here!
#5