Details
-
Bug
-
Resolution: Duplicate
-
High
-
4.7.0
-
None
-
Castor Core S3, Castor Core S4
Description
Removing an image object (or just an archived version) calls this query in eZImage::fetchImageAttributesByFilepath():
$query = "SELECT id, version
FROM ezcontentobject_attribute
WHERE contentobject_id = $contentObjectID and
contentclassattribute_id = $contentClassAttributeID and
data_text like '%url=\"$filepath\"%'";
with a large database, including multiple languages and versions for many images, the number of rows scanned becomes really large.
notes:
1 - table lacks an index for (contentobject_id, contentclassattribute_id)
2 - the LIKE clause is looking for a match in the middle of data_text, which holds an xml data string. searches with wildcards at both ends are known to be performance killers
test:
- create a structure of about 100 images in one folder
- edit some of the images to include 3 versions each
- remove a version, check the query used.
- manually check in sql the rows scanned with EXPLAIN EXTENDED
- insert an index for (contentobject_id, contentclassattribute_id)
- run EXPLAIN EXTENDED the same query
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-