[EZP-23459] eZContentObjectTreeNodeOperations::move missing features - eZ Systems JIRA tracker

Details

Type: Improvement
Status: Closed
Priority: High
Resolution: Fixed
Affects Version/s: 5.2, 2014.07, 5.3.2
Fix Version/s: Customer request, 5.2 Maintenance, 5.3.4
Component/s: Caching
Labels:
None

Description

eZContentObjectTreeNodeOperations::move has some missing features:

The site.ini [ContentSettings] CacheThreshold setting is ignored (if value exceeded, should clear all cache at the end only)
It's not checked if content view cache is enabled or disabled (EDIT: Yes, it is!)
The move operation is not handled by ezscriptmonitor (EDIT: See EZP-23504)

Issue Links

relates to

EZP-23412 Setting the section seems to avoid the delayed indexing procedure

Closed

EZP-23504 Use scriptmonitor for moving large subtrees

Open

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Georg Franz added a comment - 14/Oct/14 6:19 PM

Hi,

some notes for this issue:

it won't solve by moving the "moving" to the script monitor. It only avoids the browser timeout, but still do the cache deleting actions.
we are getting db deadlocks because the cache is deleted twice one by one (before the moving and after the moving)
please keep in mind that if you are moving 20 nodes at once it's not necerssary to delete the cache 40 times (bulk operations) - I am not sure if the bulk operations patch is "official" in the current EE distribution
thats also true for e.g. ezfind / indexing
there should be an ini setting like at the copying subtree thing: Move the moving to the script monitor if more than x nodes are affected.

Just one last question:

If you are moving a folder with 1.000 children - The moving events / workflows are only executed for the parents, not for the children, right?

Best wishes,
Georg.

Show

Georg Franz added a comment - 14/Oct/14 6:19 PM Hi, some notes for this issue: it won't solve by moving the "moving" to the script monitor. It only avoids the browser timeout, but still do the cache deleting actions. we are getting db deadlocks because the cache is deleted twice one by one (before the moving and after the moving) please keep in mind that if you are moving 20 nodes at once it's not necerssary to delete the cache 40 times (bulk operations) - I am not sure if the bulk operations patch is "official" in the current EE distribution thats also true for e.g. ezfind / indexing there should be an ini setting like at the copying subtree thing: Move the moving to the script monitor if more than x nodes are affected. Just one last question: If you are moving a folder with 1.000 children - The moving events / workflows are only executed for the parents, not for the children, right? Best wishes, Georg.

5 older comments

Hide

Permalink

Georg Franz added a comment - 27/Oct/14 4:11 PM

Hi,

is there a ticket already for the script monitor thing?

Best wishes,
Georg.

Show

Georg Franz added a comment - 27/Oct/14 4:11 PM Hi, is there a ticket already for the script monitor thing? Best wishes, Georg.

Hide

Permalink

Gunnstein Lye added a comment - 27/Oct/14 4:17 PM

Yes, issue for script monitor is here: https://jira.ez.no/browse/EZP-23504

Show

Gunnstein Lye added a comment - 27/Oct/14 4:17 PM Yes, issue for script monitor is here: https://jira.ez.no/browse/EZP-23504

Hide

Permalink

Nuno Oliveira (Inactive) added a comment - 27/Oct/14 4:21 PM

Greetings,

There is indeed, https://jira.ez.no/browse/EZP-23504.

Show

Nuno Oliveira (Inactive) added a comment - 27/Oct/14 4:21 PM Greetings, There is indeed, https://jira.ez.no/browse/EZP-23504 .

Hide

Permalink

Georg Franz added a comment - 27/Oct/14 4:22 PM

tx!

Show

Georg Franz added a comment - 27/Oct/14 4:22 PM tx!

Hide

Permalink

Pedro Resende (Inactive) added a comment - 28/Oct/14 12:01 PM

Tested by Q.A.

Show

Pedro Resende (Inactive) added a comment - 28/Oct/14 12:01 PM Tested by Q.A.

People

Assignee:

Unassigned

Reporter:

Nuno Oliveira (Inactive)

Votes:

1 Vote for this issue

Watchers:

6 Start watching this issue

Dates

Created:

13/Oct/14 6:17 PM

Updated:

28/Oct/14 12:01 PM

Resolved:

28/Oct/14 12:01 PM

Time Tracking

Estimated:

Not Specified

Remaining:

Logged:

7h 30m

Agile

View on Board