1.) When I add assign a new node to a category, a new menu item will be created.
2.) I will go to admin/menu, and i delete this new menu item. Everything goes fine untill here, the menu item is gone as espected!
3.) Only when i update the created node, you get a sql error..because the menuitem will be created again. But the record in the category_menu_map table is still present, so it's a duplicate entry.
user warning: Duplicate entry '93' for key 1 query: INSERT INTO category_menu_map (nid, mid) VALUES (93, 350) in.
Comments
Comment #1
whereisian commentedI'm having the same problem.
Not sure if it's related to these:
http://drupal.org/node/73679
http://drupal.org/node/81507
Cheers,
Ian
Comment #2
bdragon commentedPlease try again with today's version.
This bug was most likely a side effect of the category_get_parents() problem described in
http://drupal.org/node/76921
Thank you for your patience.
--Brandon
Comment #3
vatavale commentedI have the same problem (also with today's version of category module).
Comment #4
venkat-rk commentedI can confirm that this still exists with the category version of 25/09/06.
What I was doing:
1.) I had just tried multiple distant parents for a container in conjunction with pathauto (to get url paths spanning several containers and categories), but as that didn't seem to work, I reset all the containers back to having 'this container' as the distant parent.
2.) To see if I could replicate the book_load problem described in another issue, I ran a bulk update of nodes in pathauto. My placeholders were [categorypath] for containers and categories and [categorypathfirst] for all node types except event and page.
3.) The bulk update destroyed all my previous aliases and instead generated aliases for just the categories of a container (instead of container-name/category-name) or gave [categorypathfirst]-0 to 6 for story nodes that all had perfectly valid and hierarchical aliases before.
4.) I picked a category whose alias should have been
container-name/category-name, and edited it and saved the changes. I noticed that I didn't have to select the cat's parent container as it was already correctly selected. Anyhow, I saved the changes and that's when the duplicate entry error hit me.Comment #5
TheWhippinpost commentedWitnessed.
Strangely, although I was hitting this message regularly last night, tonight, it didn't occur for the first new category added, but just did for the second - Whether this is a clue pointing to a cache issue, I don't know.
Comment #6
bdragon commentedWitnessed.
Will debug.
Comment #7
bdragon commentedOk...
Multiple menu items for one node.
Looking at mysql:
Hmm....
Why is nid PRIMARY in this table? Isn't this supposed to be an N:M join table?
Comment #8
shunshifu commentedI believe I am having a similiar problem. When creating a category it creates a duplicate. When editing one I get this
Warning: Duplicate entry '421-416' for key 1 query: INSERT INTO category_hierarchy (cid, parent) VALUES (421, 416) in /home/shoushuc/public_html/includes/database.mysql.inc on line 120
Warning: Cannot modify header information - headers already sent by (output started at /home/shoushuc/public_html/includes/database.mysql.inc:120) in /home/shoushuc/public_html/includes/common.inc on line 266
When I refresh the page I get a warning that the category has been edited by another user cannot edit
Thanks
Phil
Comment #9
bdragon commented(This is now the primary issue for "duplicate entry for category_menu_map" errors.)
This patch for category_menu.install will (hopefully) fix the keys on the category_menu_map table to allow multiple mappings per node.
After patching, visit update.php and run the update for category_menu.
I'm not sure if there will be further issues or not with the actual *code*, as the primary key on the table has been wrong since the beginning, so the code to read from the table has never *encountered* multiple mids for one nid (due to them not getting stored)
Comment #10
Jaza commentedYou're right that the primary key is wrong. But in your patch, the index keys are wrong. I think that the key structure for category_menu_map should be as follows:
This is how the term_node table in core (also a M:N table), and the equivalent category_node table, does it. Updated patch that implements this index structure. Let me know if it looks OK, and I'll commit it.
Comment #11
bdragon commentedOk, I'm okay with mid being just (mid) (as we probabaly don't need to order by nid) but the nid (nid) is a duplicate of the first part of the primary key.
Comment #12
bdragon commentedOne reason to have the indexes like I had them is the ability to serve data directly out of the index.
"In some cases, a query can be optimized to retrieve values without consulting the data rows. If a query uses only columns from a table that are numeric and that form a leftmost prefix for some key, the selected values may be retrieved from the index tree for greater speed"
Comment #13
Jaza commented@bdragon: perhaps you'd be able to explain a few things to me, as it looks like you know more about database indexing than me (I admit that I'm not an expert on the subject, I just pick up what I can):
(field1, field2)different to(field2, field1), and if so, how?(field1, field2), and two separate keys of(field1),(field2)? And which type of key(s) is better in the case of category_menu_map?I'm willing to follow your advice and judgement, but I'd like to understand as much as I can before committing anything. :P
Also, answering my questions by saying 'RTFM' and pointing me to a URL is fine. I don't expect you to go out of your way explaining the intricacies of database indexing to me (or to anyone else, for that matter).
Comment #14
bdragon commentedYes. MySQL can only read indexes left to right. The index is not even *considered* unless it can start a match with the leftmost part of the index. The first parts of the key should be the WHERE conditions, followed by any ORDER BY conditions, or in our case, the data.
"SELECT field2 FROM table WHERE field1 = 11111" would not be able to use the (field2,field1) key.
"SELECT field1 FROM table WHERE field2 = 11111" would not be able to use the (field1,field2) key.
If both keys are in place, and field1 and field2 are INTEGERs, both of those queries can be performed entirely within the index.
The seperate keys are smaller, which is a good thing in most circumstances.
_However_, this is a join table. Having a forwards and backwards key that uses both columns means MySQL can bypass the data table completely, as all the needed data is stored directly in the index. That makes joins faster.
http://dev.mysql.com/doc/refman/4.1/en/explain.html
http://dev.mysql.com/doc/refman/4.1/en/mysql-indexes.html
Comment #15
Jaza commentedAttached patch is the same as bdragon's patch from #9 (above), with minor code cleanup. Patch committed to HEAD and 4.7.
Thanks for explaining the logic behind your choice of indexing, bdragon. I think I understand now why the new structure is more appropriate for the category_menu_map table. Anyway, being a developer is all about learning - thanks for teaching me something very useful!
Comment #16
(not verified) commentedComment #17
hectorplus commentedOk, i just downloaded the latest release of category(Dated nov. 11), it said it updated the category_menu_map file, but the issues is not fixed. I still get a duplicate erro.
I am not familiar in using the .patch thing, do you know of any tutorial. I am using eclipse. Thanks
Comment #18
transformative commentedhttp://drupal.org/patch/apply
Comment #19
fluitfries commentedwhy is this issue closed? i have the latest patch installed, even checked my live files against HEAD and dev, and the patch itself, and this issue is not fixed for me.
could it be because i have had the issue for so long and now there might be problems in my db? do i need to do any sort of uninstall/install of the module? please help!