upgrade to 3.5.1 : deleting takes 10 minutes?...

Author Message

Gioele Agostinelli

Saturday 05 March 2005 8:34:55 pm

Hi folks,

i just upgrade from 3.2.3 to 3.5.1. Everything seems fine but when i try to delete something (an article for example) it takes around 10 minutes! After investigation i always have a query similar to this one running when deleting:

| Query | 569 | Copying to tmp table | INSERT INTO eznode_count
SELECT
count( ezcot.main_node_id ) AS count
FROM
ezcontentobject_tree ezcot RIGHT JOIN
ezcontentobject_tree ezcot_all ON ezcot.main_node_id = ezcot_all.main_node_id
WHERE
ezcot.path_string like '/1/2/13540/%' and
ezcot.node_id != 13540
GROUP BY ezcot_all.main_node_id |

I'm on mysql 3.23.58. I have a large site with a lot of articles but i think that 10 minutes isn't normal... Thanks for the help and have a nice day!

Gioele

Raymond Bosman

Wednesday 09 March 2005 4:52:37 am

Ten minutes is not normal indeed. Can you check whether the main_node_id field of the ezcontentobject_tree table has an index?

If not create one on the main_node_id, this will definitely save a lot of time.

Raymond

Gioele Agostinelli

Wednesday 09 March 2005 1:10:08 pm

Hi Raymond,

Thank you for your suggestion, I added an index on main_node_id and now deletion of an object takes less then a second. The index isn't part of the sql schema by default; I think it should be a good idea to add it by default in next version of ez.

I also have another suggestion, I don't know if it is 100% bullet-proof but here it is anyway....

If I understood correctly, the query that was taking for ever is in subtreeSoleNodeCount(). This function is called by removeSubtrees() in kernel/classes/ezcontentobjecttreenode.php. If the object you are trying to delete isn't a container there shouldn't be any subtree and therefore no need to call the function subtreeSoleNodeCount() since it should always return 0. So I replaced the call of subtreeSoleNodeCount() in removeSubtrees() by :

if ( !$class->attribute( 'is_container' ) )
{
$soleNodeCount =0;
}
else
{
$soleNodeCount = $node->subtreeSoleNodeCount();
}

Since the only objects that I delete are articles which are not container on my site, deletion time returned to normal.

The modification is a bit dirty since the verification should be done in subtreeSoleNodeCount() and not in removeSubtrees()... but I was in a hurry... I'm sure you get the idea... there is no need to run the query if the object is not a container.

If I'm correct maybe it would be a good idea to add this kind of verification in next version of ez also.

Thank you again for your suggestion and have nice day!

Gioele

Jan Borsodi

Friday 11 March 2005 1:45:25 am

The <i>is_container</i> flag is merely meant as a user-interface hint than a strict rule for objects. This means that it is quite possible for an object to have children (e.g comments).

The reason why we check for children for all objects is to give the user feedback on how many children are going to be deleted. If we add this check children may be accidently removed.

--
Amos

Documentation: http://ez.no/ez_publish/documentation
FAQ: http://ez.no/ez_publish/documentation/faq

Ekkehard Dörre

Monday 29 August 2005 5:59:58 am

Same Problem with 3.5.3
MySQL 3.23.49-log debian 40 sec., creating index didn't help, same istallation on testserver xp with MySQL 4.0.20a in 3 sec

Deleting 1 Object. Any Ideas?

SOLVED, it is voodoo, tried it again after 10 minutes, now it works.

Thanks, ekke

http://www.coolscreen.de - Over 40 years of certified eZ Publish know-how: http://www.cjw-network.com
CJW Newsletter: http://projects.ez.no/cjw_newsletter - http://cjw-network.com/en/ez-publ...w-newsletter-multi-channel-marketing

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.