Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I updated menu_node from 1.3 to 1.4. Before I applied the update I looked at the menu_node table. There are 459 rows. 458 are distinct. I made no alteration to the table.
The update didn't apply fully because of the duplicate in the menu_node table.
Here's the the relevant part of the output...
Update #6002
* ALTER TABLE {menu_node} DROP PRIMARY KEY
* Failed: ALTER TABLE {menu_node} DROP INDEX nid
* Failed: ALTER TABLE {menu_node} ADD PRIMARY KEY (mlid)
* ALTER TABLE {menu_node} ADD INDEX nid (nid)
Comment | File | Size | Author |
---|---|---|---|
#22 | 1018692-update.patch | 1.51 KB | agentrickard |
#13 | duplicates.png | 38.64 KB | matglas86 |
#4 | menu_node.install.patch | 894 bytes | matglas86 |
#2 | Screen shot 2011-01-07 at 1.32.05 PM.png | 49.48 KB | agentrickard |
Comments
Comment #1
agentrickardWhat kind of DB are you using? Did you use the patch or the released code version?
Comment #2
agentrickardWorks fine on my test box.
Comment #3
agentrickardWhat were the non-unique rows in your table? Did update_6001 not clear them out?
Comment #4
matglas86 CreditAttribution: matglas86 commentedI was having this same problem. Here is how it fixed the duplicate records that already where in the table. This query selects all the duplicate nodes that are referenced. Thats only 'node/%'. The patch should be rolled against version 1.4.
Comment #5
matglas86 CreditAttribution: matglas86 commentedForgot to change the status. Please review my patch in the previous post.
Comment #6
agentrickardI still need my initial question answered. It is legitimate to have two MLIDs pointing to the same NID, so what are you considering the "duplicate rows"?
Comment #7
bstoppel CreditAttribution: bstoppel commentedI had the same mlid but it was pointing to two different nids. I only had one duplicate though.
Comment #8
agentrickardThanks. I really don't like the query in #4 and wonder if it can be made a little nicer. I fear it won't run on all platforms.
Comment #9
matglas86 CreditAttribution: matglas86 commentedOk I think I did not get a question out of the initial post. A MLID should always point to one node if its to a node. Basically a MLID always has 1 destination. But your question is the other way round. Two MLID's to one NID. That is a no problem and should be able. Two menu items (e.a. MLID records) can both have the same end destination.
But my problem was different and should be fixed with the MLID as a primary key. When items where added is check against the primary key combination of MLID and NID. This created duplicate MLID's in my menu_node table. The module update fixed the primary key problem but not the duplicate MLID's that where already in my menu_node table because of the behavior of the previous version.
With the code I posted above I tried to fix that and clean out the duplicate MLID's in the table. When I leave them in there the change to a single primary key could not be done. It would give a error.
@agentrickard: I know that the query is not that nice. I tried to keep it simple but had to do a check for count. This is just a start.
I hope this explains my approach above.
Comment #10
agentrickardYes, thanks. The question was in #3.
Comment #11
bstoppel CreditAttribution: bstoppel commentedI just realized that I missed the questions in #1.
The database is MySQL 5.0.51a . I used the release code.
Comment #12
agentrickard:-) What I'd really like is someone to copy a sample of "duplicate rows",which I suspect looks like so:
In this case, I think we have to delete all the dupes and rebuild from {menu_links}.
Comment #13
matglas86 CreditAttribution: matglas86 commentedHere is a example of the duplicates I had.
Comment #14
agentrickardI think we run that query, then loop through and delete any entries where the NID doesn't match the expected path.
Comment #15
bstoppel CreditAttribution: bstoppel commentedNot sure this will help or not, but here are a few rows from my {menu_node} table
mlid | nid
3649 | 29
3649 | 35 <- this was the offending row in my case. I deleted it.
815 | 29
The nid 29 is in two different menus, which is desired.
Comment #16
agentrickard@bstoppel
What do you get when you run the query shown here --> http://drupal.org/files/issues/duplicates_0.png
Comment #17
matglas86 CreditAttribution: matglas86 commented@agentrickard What do you mean by #14 "I think we run that query"? Do you mean that the query is already in the module? If it does somehow it does not accomplish the desired effect.
Comment #18
agentrickardNo, I mean "I think the solution is to run the query and loop through the results."
Comment #19
matglas86 CreditAttribution: matglas86 commentedWhen you loop through the results you will be deleting and and regenerating references right?
Comment #20
agentrickardYes.
Comment #21
matglas86 CreditAttribution: matglas86 commentedSo it would look something like this. I didnt test the function yet the results of the query are good though.
Comment #22
agentrickardCorrect, though we actually have to duplicate the update functions for things to work properly, but that won't cause any harm.
If this tests OK, we can roll a new release.
Comment #23
matglas86 CreditAttribution: matglas86 commentedJust a minor thing to keep the code clean, remove '// This is the new part.'
Hope I'm not a pain in the ass. :-)
Comment #24
agentrickardCommitted and released. Thanks for sticking with this one.
Comment #25
matglas86 CreditAttribution: matglas86 commentedIts no problem. I'm glad that I could help. All the little things make Drupal the best. :)