When freetagging an item, and using the same tag twice, a database error will occur. For example: linux, eeg, linux, super-fries

The linux tag will yield:

Warning: Duplicate entry '2-1' for key 1 query: INSERT INTO term_node (nid, tid) VALUES (1, 2) in /drupal-cvs/includes/database.mysql.inc on line 108
CommentFileSizeAuthor
#18 free_tag_dupes_0.patch1.38 KBJaza
#12 free_tag_dupes.diff1.49 KBmoshe weitzman
#5 unique_tags.patch727 bytesDriesK
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Junyor’s picture

Junyor CreditAttribution: Junyor commented
Status: Active » Closed (duplicate)

Duplicate of http://drupal.org/node/40945.

adam.skinner’s picture

adam.skinner CreditAttribution: adam.skinner commented
Status: Closed (duplicate) » Active

This is not a duplicate issue. Please note that this occurs when entering the same tag twice for a node using freetagging.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Priority: Normal » Minor
Status: Active » Closed (works as designed)

what kind of fool adds same tag twice?

Junyor’s picture

Junyor CreditAttribution: Junyor commented
Status: Closed (works as designed) » Active

How is this by design? What if you add it accidentally? That shouldn't cause a DB error.

DriesK’s picture

DriesK CreditAttribution: DriesK commented
Assigned: Unassigned » DriesK
Status: Active » Needs review
FileSize
unique_tags.patch727 bytes

Although chances of this happening are small, I agree with Junyor that when someone uses the same tag twice by accident, this shouldn't cause a db error.

I don't think we need to issue a form error and instruct the user to remove the duplicate. Instead, I suggest we let Drupal handle this silently (see attached patch).

Dries’s picture

Dries CreditAttribution: Dries commented

Related to http://drupal.org/node/37829 ?

adam.skinner’s picture

adam.skinner CreditAttribution: adam.skinner commented
Status: Needs review » Reviewed & tested by the community

Patch works great!

I don't suppose you'd believe me if I told you I tried the same thing but it didn't work for me before. I must have put it in the wrong place (I'm not really a php coder, but I found the array_unique function and put it in where it looked like it belonged).

Anyway, that fixed the problem! Thanks DriesK!

adam.skinner’s picture

adam.skinner CreditAttribution: adam.skinner commented

I'm going to leave this as "ready to be committed", but I would like to bring up one outstanding issue: capitalization. array_unique doesn't do the case-insensitivity thing, so if we put in "linux, pancakes, Linux, home-skillet", we'll get the duplicate node error.

Obviously, the downside of lower-casing the whole thing is that when new taxonomy terms get added, they would be added without the original casing.

Cvbge’s picture

Cvbge CreditAttribution: Cvbge commented

Are freetags lowecased? If not, "linux" and "Linux" are 2 different tags.

adam.skinner’s picture

adam.skinner CreditAttribution: adam.skinner commented

When a tag is inserted via freetagging, it retains it's case. So if you tag something "Linux", it will insert "Linux" as the name in term_data. Thereafter, whether you put in "LiNUx" or "linux", it will find the term and associate it. So tag matching is not case-sensitive, but tag insertion retains case.

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Reviewed & tested by the community » Needs work

So I guess this needs more work?

It would be nice to look at http://drupal.org/node/37829 as well.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Status: Needs work » Reviewed & tested by the community
FileSize
free_tag_dupes.diff1.49 KB

i added some more defensiveness so we don't attempt an insert when adding two terms of slightly different case

Dries’s picture

Dries CreditAttribution: Dries commented

Correct me if I'm wrong, but even with the extra defensiveness, it's prone to errors? I guess the only way to fix it is to do a SELECT-query before the INSERT-query (while holding a table lock).

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

@Dries - you are correct. I'd rather not lock for every taxonomy add/edit. I'd say that his is good enough for now. My .02

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Reviewed & tested by the community » Needs work

Even without a table lock, one can have duplicates, I'm afraid. Please set back to RTBC if I'm wrong.

Morbus Iff’s picture

Morbus Iff
they/them
CreditAttribution: Morbus Iff commented

For what it's worth, and I'm just spouting here because I"ve not yet looked more in-depth into the patch, duplicates should be case-sensitive. If Dries makes a revolutionary window washing technique, "Dries" and "dries" are quite different freetags, and should remain as such. (Worst. Example. EVAH!)

Egon Bianchet’s picture

Egon Bianchet CreditAttribution: Egon Bianchet commented
Version: 4.7.0-beta1 » 4.7.0

Still present in 4.7.0

Jaza’s picture

Jaza CreditAttribution: Jaza commented
Status: Needs work » Needs review
FileSize
free_tag_dupes_0.patch1.38 KB

Patch for latest HEAD / 4.7. Same as #12 by moshe, except that in_array() check has been changed to isset().

Oh, and did I mention +1 for this idea?

killes@www.drop.org’s picture

killes@www.drop.org CreditAttribution: killes@www.drop.org commented
Version: 4.7.0 » x.y.z
Status: Needs review » Reviewed & tested by the community

Applied to 4.7

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm commented
Status: Reviewed & tested by the community » Fixed

Committed to HEAD.

Anonymous’s picture

(not verified) CreditAttribution: commented
Status: Fixed » Closed (fixed)