-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EZP-27101: Remove recursion when retrieving search metadata for relation fields #1372
EZP-27101: Remove recursion when retrieving search metadata for relation fields #1372
Conversation
@natanael89 for the BC break, can you add description of that in doc/bc/5.90/relation_indexing.md ? This will be for the 2018.06 release. |
} | ||
|
||
$datatype = $attribute->dataType(); | ||
if($skipRelationAttributes && $datatype->isRelationType()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
legacy cs: if ( $skipRelationAttributes && $datatype->isRelationType() )
@@ -68,7 +68,6 @@ public function addObject( $contentObject, $commit = true ) | |||
$placement = 0; | |||
$previousWord = ''; | |||
|
|||
eZContentObject::recursionProtectionStart(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wondering if we might need to keep these in, in case custom relation field types still use it.
or will it cause problems?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can (and should) keep those, you are right.
I added the BC description and made the suggested fixes. |
@@ -1182,7 +1182,7 @@ static function metaDataArray( &$attributes, $skipRelationAttributes = false ) | |||
} | |||
|
|||
$datatype = $attribute->dataType(); | |||
if($skipRelationAttributes && $datatype->isRelationType()) | |||
if( $skipRelationAttributes && $datatype->isRelationType() ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my prev comment forgot to also specify whitespace after if
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
@@ -0,0 +1,13 @@ | |||
# Relation search indexing changes | |||
|
|||
For the 2018.06 release, eZ Publish changed the way relations are indexed. Previously the relation metadata was loaded recursively, meaning that relations of relations etc. were also included. This behavior was changed to only include Objects one level deep so only direct relations are taken into account. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot the "more relevant search result" part, indeed, what is mainly significant for relevance is first level relations.
…ion fields (ezsystems#1372) * Fix EZP-27101: Remove recursion when retrieving search metadata * fixup! Fix EZP-27101: Remove recursion when retrieving search metadata * fixup! Fix EZP-27101: Remove recursion when retrieving search metadata
JIRA issue: EZP-27101
When retrieving the search metadata from objects containing "Object relation" and "Object relations" field type, there is a recursion protection in place that ensures that there is no infinite recursion caused by circular references. However, it only checks if the certain object was already processed and this is causing problems when the same object is referenced from two different fields (as described in EZP-27101).
This PR removes the recursion completely by making the relations load metadata only one level deep. By removing recursion, I was also able to remove the recursion protection, which solves the original issue.
This PR introduces a slight BC break because it changes logic (previously the metadata was loaded recursively and now it is loaded only one level deep), but the new behavior allows for better (more relevant) search results.
An alternative solution (without a BC break, but which keeps the broken logic of loading the metadata recursively) can be found here: #1371.