Taxonomy - Duplicate node names is a problem?

I ran into this issue and hoping its a bug that has been fixed. I do have a ticket open as well.

We are starting a new implementation for livesite. In our current design, we have few branches that have very similar set of taxonomy node names. The authors for each branch also have the ability to add new nodes and use them for tagging.

The problem we just ran into is: when I created branch2 and added the node "Department Type", my workflow failed with the following error

2015-01-05 10:49:21,004 INFO [STDOUT] [ERROR] 10:49:21 JDBCExceptionReporter - Violation of UNIQUE KEY constraint 'UQ__iwtax_no__656F8F03778AC167'. Cannot insert duplicate key in object 'dbo.iwtax_node_type'. The duplicate key value is (Department Type).

To me, this doesn't make sense. Every Node has a unique node_id, so the additional unique_key constraint has me baffled.

Is this just a bug on my system - or is this how its designed?

This has me wondering if our view of taxonomy and how we use it is misplaced.

Any thoughts?

7.3.2, Linux based installation.

Find more posts tagged with

Comments

Ashish_Sangal

Hi,

Can you upload the taxonomy file from both the branches.

Path - /default/main/hp-event/WORKAREA/work/iw/config/taxonomy/branch.taxonomies

Also, did you copy this file from one branch to another?

argh_teamsite

Attaching three taxonomy files.

Branch A - where I created the original taxonomy node.

Branch B - before and after.

The taxonomy node in question is called "camping-hiking"

Also talked to HP folks over the last week. It seems "this is a featuer not a bug" :-)

What I got from them is:

Two taxonomy nodes, "Contenty Type" and "Content Categories" are created by default. You'll see they have the same id.
The Taxonomy Manager allows you to create new nodes but if you have two taxonomy nodes with the same name - the corresponding DB constraint fails. Note that this doesn't apply to the internal nodes.
I asked the HP rep how do I add more nodes to the default set (#1 above) - She didn't know and wanted to recommend professional services to me.

Bowker

There are some pretty big changes to the way 7.2.1 and 7.4.1 processes Taxonomy files.

I don't know if those changes occurred in 7.3 or 7.4. Things appear to be "working now" in 7.4.1 but since we skipped 7.3 I'm may not be on track here.

We have many duplicate names in our taxonomy. But we have only one active Branch with any taxonomies. By any chance did someone copy the branches.taxonomy file from one branch to another - that would be bad.

argh_teamsite

I wonder if this is fixed in 7.4 - the HP rep didn't say (I will ask)

She was able to reproduce it in her environment.

Nope we didn't copy the taxonomy files from another branch.

When I look in the RT database (image attached); it specifies the constraint that name be unique (not just the key, as you would expect). Note this only applies to top level taxonomy node. Internal nodes are fine - they are stored in a separate table and dont have this constraint.

I wonder if you see a similar DB rule in 7.4 databases.

Bowker

I agree that "name" should not have to be unique. The id is used everywhere I've seen.

But to answer your question - NO nodetype_name is still a unique index in 7.4.1 - sorry.

argh_teamsite

Hey thanks for checking Dan.

Our current decision is to just go with "Content Types" and not create new top level nodes unless we absolutely need them.

Thanks!

Bowker

We've come to the same conclusion. It also allow for easier handling later. It's a little messy for end-users to select items, but faster/easier if you want to add a new "Taxonomy" since all the fields are alread there, LSCS already knows about them, DCRs and Components don't need to be touched...

All sorts of things become easier to code but the business person who updates content is then forced to look things up in a long list.

It would be possible to limit that issue but we've not been approached to do so.

Good Luck