diff options
Diffstat (limited to 'library/Icingadb/Model/Behavior/FlattenedObjectVars.php')
-rw-r--r-- | library/Icingadb/Model/Behavior/FlattenedObjectVars.php | 29 |
1 files changed, 24 insertions, 5 deletions
diff --git a/library/Icingadb/Model/Behavior/FlattenedObjectVars.php b/library/Icingadb/Model/Behavior/FlattenedObjectVars.php index b1c308a..8b110e0 100644 --- a/library/Icingadb/Model/Behavior/FlattenedObjectVars.php +++ b/library/Icingadb/Model/Behavior/FlattenedObjectVars.php @@ -32,11 +32,30 @@ class FlattenedObjectVars implements RewriteColumnBehavior, QueryAwareBehavior $column = $condition->metaData()->get('columnName'); if ($column !== null) { $relation = substr($relation, 0, -5) . 'customvar_flat.'; - $nameFilter = Filter::like($relation . 'flatname', $column); - $class = get_class($condition); - $valueFilter = new $class($relation . 'flatvalue', $condition->getValue()); - - return Filter::all($nameFilter, $valueFilter); + $condition->metaData() + ->set('requiresTransformation', true) + ->set('columnPath', $relation . $column) + ->set('relationPath', substr($relation, 0, -1)); + + // The ORM's FilterProcessor only optimizes filter conditions that are in the same level (chain). + // Previously, this behavior transformed a single condition to an ALL chain and hence the semantics + // of the level changed, since the FilterProcessor interpreted the conditions separately from there on. + // To not change the semantics of the condition it is required to delay the transformation of the condition + // until the subquery is created. Though, since this is about custom variables, and such can contain dots, + // the FilterProcessor then continues traversing the parts of the column's path, which then would include + // the dot-separated parts of the custom variable name. To prevent this, we have to signal that what we + // return a replacement here, that should be used as-is and not processed further. + $condition->metaData()->set('forceResolved', true); + + // But to make it even worse: If we do that, (not transforming the condition) the FilterProcessor sees + // multiple conditions as targeting different columns, as it doesn't know that the *columns* are in fact + // custom variables. It then attempts to combine the conditions with an AND, which is not possible, since + // they refer to the same columns (flatname and flatvalue) after being transformed. So we have to make + // the condition refer to a different column, which is totally irrelevant, but since it's always the same + // column, the FilterProcessor won't attempt to combine the conditions. The literal icing on the cake. + $condition->setColumn('always_the_same_but_totally_irrelevant'); + + return $condition; } } |