Re: Restoring deleted content and recycle bin content

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restoring deleted content and recycle bin content

Dan Wilga-2
After a greatly appreciated effort on Hilary's part, she was able to
create a reproducible test case for this bug. I have fixed it, and the
change appears in 7.x-1.18.

On 8/6/14 3:09 PM, Hilary Caws-Elwitt wrote:

> I'm testing the patch and still get the PDOException sometimes. Can't reliably reproduce this yet, but here's more or less what happens:
>
> 1. Sending a branch to the recycle bin (possibly a branch that already contains a recycle bin 2+ levels down, plus some other condition) generates sort index errors
> 2. Say the parent is A, the branch B, and R is the new recycle bin containing B. Errors are:
> --B has impossible parent [...R] when mm_tree_parents says they should be [( whatever),A,R].
> --All B's subpages have a parent (A) inconsistent with their sort order.
> 3. (If I click to fix all errors, even the first error which states it can't be fixed automatically is in fact fixed, and everything is fine...)
> 4. If the errors are not fixed and the recycle bin is emptied, the integrity constraint violation on duplicate entry is triggered.
> 5. After that, verifying the sort index shows "MM Tree entry [mmtid of recycle bins that were in the tree] has missing parent [page that was deleted]. Testing halted." mm_cascaded_settings refers to missing mmtids too, which seems to do strange things to neighboring pages as well.
>
> --
> Hilary Caws-Elwitt
> IT Analyst - Five Colleges, Inc. - http://www.fivecolleges.edu
> 97 Spring St, Amherst MA 01002
> [hidden email] - 413-542-4022
>
> -----Original Message-----
> From: Dan Wilga [mailto:[hidden email]]
> Sent: Wednesday, August 06, 2014 9:47 AM
> To: Monster Menus Development
> Subject: Re: Restoring deleted content and recycle bin content
>
> It's not easily possible (or, in my opinion, desirable) to limit the number of items in a bin. However, it should be more reliable if the action is wrapped in a transaction. For anyone wanting to try it out, the commit is fdecee, or you can use the attached patch.
>
> On 8/5/14 1:46 PM, Hilary Caws-Elwitt wrote:
>> Follow-up: it's not related to having emptied the bin too soon, but maybe to the complexity of the structure being deleted? Restoring a complex structure seems to create other issues (now getting mm_cascaded_settings.mmtid refers to missing mm_tree.mmtid errors). Would it be possible/desirable to limit the # of pages and/or nodes and/or levels of nesting that can "fit" in one recycle bin?
>> --
>> Hilary Caws-Elwitt
>> IT Analyst - Five Colleges, Inc. - http://www.fivecolleges.edu
>> 97 Spring St, Amherst MA 01002
>> [hidden email] - 413-542-4022
>>
>>
>> -----Original Message-----
>> From: Hilary Caws-Elwitt [mailto:[hidden email]]
>> Sent: Tuesday, August 05, 2014 11:49 AM
>> To: Monster Menus Development
>> Subject: RE: Restoring deleted content and recycle bin content
>>
>> Hmmm.... interesting to hear, and maybe related to the issues I'm seeing. I was deleting some branches on our production site and ran into a problem. Comparing to older DB copies in two testing instances, here’s the situation as best I can reconstruct it:
>>
>> Snapshot from June: No MM integrity issues. A recycle bin contains pages A, B, and C, all hidden. C has 2 further subpages, D and E.
>>
>> Snapshot from July: mm_tree_access.mmtid refers to missing mmtids for C, D, and E only (not A or B).
>>
>> Today: I delete a hidden page with 25 subpages. When I empty the recycle bin, I get a site error. The bin and its contents do get deleted, but looking in the logs there are two SQLSTATE[23000]: Integrity constraint violations (pasted below). Now I have mm integrity errors on missing mmtids for mm_recycle.from and bin, and mm_tree.parent, as well as tons in mm_tree_access.
>>
>> But I did not realize how long it can take to move contents to a recycle bin, so I may have triggered the issue by clicking permanently delete too soon? Aaargh! How to handle the MM integrity errors?
>>
>> Here's the error text from the log:
>>
>> PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'node-24209-0' for key 'PRIMARY': UPDATE {mm_recycle} SET from_mmtid=:db_update_placeholder_0 WHERE (type = :db_condition_placeholder_0) AND (from_mmtid IN (:db_condition_placeholder_1, :db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4, :db_condition_placeholder_5, :db_condition_placeholder_6, :db_condition_placeholder_7, :db_condition_placeholder_8, :db_condition_placeholder_9, :db_condition_placeholder_10, :db_condition_placeholder_11, :db_condition_placeholder_12, :db_condition_placeholder_13, :db_condition_placeholder_14, :db_condition_placeholder_15, :db_condition_placeholder_16, :db_condition_placeholder_17, :db_condition_placeholder_18, :db_condition_placeholder_19, :db_condition_placeholder_20, :db_condition_placeholder_21, :db_condition_placeholder_22, :db_condition_placeholder_23, :db_condition_placeholder_24, :db_condition_placeholder_25, :db_condition_placeholder_26)) ; Array ( [:db_update_placeholder_0] => 0 [:db_condition_placeholder_0] => node [:db_condition_placeholder_1] => 9280 [:db_condition_placeholder_2] => 4369 [:db_condition_placeholder_3] => 6188 [:db_condition_placeholder_4] => 6189 [:db_condition_placeholder_5] => 6190 [:db_condition_placeholder_6] => 6191 [:db_condition_placeholder_7] => 6192 [:db_condition_placeholder_8] => 6257 [:db_condition_placeholder_9] => 6258 [:db_condition_placeholder_10] => 6259 [:db_condition_placeholder_11] => 5722 [:db_condition_placeholder_12] => 5723 [:db_condition_placeholder_13] => 5724 [:db_condition_placeholder_14] => 5725 [:db_condition_placeholder_15] => 5387 [:db_condition_placeholder_16] => 4373 [:db_condition_placeholder_17] => 4370 [:db_condition_placeholder_18] => 4371 [:db_condition_placeholder_19] => 4372 [:db_condition_placeholder_20] => 4421 [:db_condition_placeholder_21] => 4422 [:db_condition_placeholder_22] => 4423 [:db_condition_placeholder_23] => 4424 [:db_condition_placeholder_24] => 4425 [:db_condition_placeholder_25] => 4426 [:db_condition_placeholder_26] => 5054 ) in mm_content_delete() (line 2613 of /var/www/html/production/sites/all/modules/monster_menus/mm_content.inc).
>>
>> PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'node-45940-0' for key 'PRIMARY': UPDATE {mm_recycle} SET from_mmtid=:db_update_placeholder_0 WHERE (type = :db_condition_placeholder_0) AND (from_mmtid IN (:db_condition_placeholder_1, :db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4, :db_condition_placeholder_5, :db_condition_placeholder_6, :db_condition_placeholder_7, :db_condition_placeholder_8, :db_condition_placeholder_9, :db_condition_placeholder_10, :db_condition_placeholder_11, :db_condition_placeholder_12, :db_condition_placeholder_13, :db_condition_placeholder_14, :db_condition_placeholder_15, :db_condition_placeholder_16, :db_condition_placeholder_17, :db_condition_placeholder_18, :db_condition_placeholder_19, :db_condition_placeholder_20, :db_condition_placeholder_21, :db_condition_placeholder_22, :db_condition_placeholder_23, :db_condition_placeholder_24, :db_condition_placeholder_25, :db_condition_placeholder_26, :db_condition_placeholder_27)) ; Array ( [:db_update_placeholder_0] => 0 [:db_condition_placeholder_0] => node [:db_condition_placeholder_1] => 9282 [:db_condition_placeholder_2] => 6277 [:db_condition_placeholder_3] => 6282 [:db_condition_placeholder_4] => 8249 [:db_condition_placeholder_5] => 6285 [:db_condition_placeholder_6] => 6286 [:db_condition_placeholder_7] => 6287 [:db_condition_placeholder_8] => 6288 [:db_condition_placeholder_9] => 6289 [:db_condition_placeholder_10] => 6290 [:db_condition_placeholder_11] => 6291 [:db_condition_placeholder_12] => 6661 [:db_condition_placeholder_13] => 6292 [:db_condition_placeholder_14] => 6293 [:db_condition_placeholder_15] => 6294 [:db_condition_placeholder_16] => 6295 [:db_condition_placeholder_17] => 6296 [:db_condition_placeholder_18] => 6297 [:db_condition_placeholder_19] => 6298 [:db_condition_placeholder_20] => 6299 [:db_condition_placeholder_21] => 6300 [:db_condition_placeholder_22] => 6301 [:db_condition_placeholder_23] => 6302 [:db_condition_placeholder_24] => 6303 [:db_condition_placeholder_25] => 6304 [:db_condition_placeholder_26] => 6305 [:db_condition_placeholder_27] => 6306 ) in mm_content_delete() (line 2613 of /var/www/html/production/sites/all/modules/monster_menus/mm_content.inc).
>> --
>> Hilary Caws-Elwitt
>> IT Analyst - Five Colleges, Inc. - http://www.fivecolleges.edu
>> 97 Spring St, Amherst MA 01002
>> [hidden email] - 413-542-4022
>>
>>
>> -----Original Message-----
>> From: Jay Dansand [mailto:[hidden email]]
>> Sent: Tuesday, August 05, 2014 11:36 AM
>> To: Monster Menus Development
>> Subject: RE: Restoring deleted content and recycle bin content
>>
>> Similarly, we had a number of issues with Recycling Bins that we also could never reproduce to fix.  It was sufficiently gumming up the works that we just ended up disabling them.  Teaching our editors that "delete means delete" has in practice been easier than staying current on fixing the weird limbo nodes/pages.  If someone truly needs to get stuff back, we have an internal site that we just reset to an arbitrary database point in time and we let them copy their content back by hand (it's only happened once in the past year).
>>
>>
>> --
>> Jay Dansand '08
>> Senior Web Application Developer
>> Technology Services, Seeley G. Mudd Library Lawrence University
>> Appleton, WI
>> 920-832-6585
>> [hidden email]
>>
>>
>> -----Original Message-----
>> From: Dan Wilga [mailto:[hidden email]]
>> Sent: Tuesday, August 05, 2014 10:19 AM
>> To: Monster Menus Development
>> Subject: Re: Restoring deleted content and recycle bin content
>>
>> I have run into cases where content can end up both inside and outside of a bin, but have never been able to reproduce it reliably enough to fix. I believe the problem is related to the complexity of creating a bin and moving the nodes/pages, particularly when a large number of things are being moved and the connection either times out or the user stops the process.
>>
>> When nodes are deleted from a bin, their data is truly gone from the current database. The only way to get them back is from a backup. And, unfortunately, there is no way to get the MM structure back easily from the backup. Something like this would get you part way there:
>>
>>      SELECT mmtid FROM mm_tree_parents p WHERE p.parent = [mmtid of top
>> page deleted]
>>
>> This gets you the mmtids of all subpages that were deleted. So:
>>
>>      SELECT nid FROM mm_node2tree WHERE mmtid IN(SELECT mmtid FROM
>> mm_tree_parents p WHERE p.parent = [mmtid of top page deleted])
>>
>> gets you the nids that were deleted. Basically, you should probably restore at least the data in these MM tables:
>>
>>      mm_tree
>>      mm_node2tree
>>      mm_node_write
>>      mm_tree_access
>>      mm_group (relate gid to mm_tree_access, where gid < 0)
>>      mm_tree_flags
>>      mm_tree_parents
>>
>> On 8/5/14 8:08 AM, grahamtk wrote:
>>> Hi!
>>> I turned on automatic removal from recycle bin, and it turns out
>>> someone have moved content from deleted parent pages into the normal
>>> tree. this should not be possible if you ask me, or the action should
>>> at least have restored the moved pages from the bin - as when I
>>> emptied the bin, moved pages that now lived outside the bin was also removed.
>>>
>>> Another case is maybe like ressurecting dead nodes.. I have turned on
>>> automatic emptying of recycle bins, and alas a large important branch
>>> from the content turned up to have been wrongfully deleted during a
>>> holiday, and was deleted automatically.
>>>
>>> Are there any ways to restore this from the current database? or do
>>> we have to restore it from a backup?
>>> and how would you go about that? I have site backups, and might for
>>> instance export it from a restored site with views xml, and import
>>> it, but what about the mm structure, as long as I have not got nodeporter mm to work on d7 yet.
>>>
>>> Thanks in any case.
>>>
>
> ---
> You are currently subscribed to monster_menus as: [hidden email].
> To unsubscribe click here: http://lists.middlebury.edu/u?id=1034715.d8dc340b0014c740c37e95754e54e1f3&n=T&l=monster_menus&o=704877
> or send a blank email to [hidden email]
>
> ---
> You are currently subscribed to monster_menus as: [hidden email].
> To unsubscribe click here: http://lists.middlebury.edu/u?id=685500.19fa7de7038497527f6a88cf1629251d&n=T&l=monster_menus&o=704910
> or send a blank email to [hidden email]



---
You are currently subscribed to monster_menus as: [hidden email].
To unsubscribe click here: http://lists.middlebury.edu/u?id=685503.6b071f880fe6a965a128164e6d09ea81&n=T&l=monster_menus&o=705875
or send a blank email to [hidden email]
Loading...