From c7dae01533837a7f78dc9637c7f30e32d1cae504 Mon Sep 17 00:00:00 2001 From: Johannes Meyer Date: Fri, 19 Jul 2024 14:16:35 +0200 Subject: [PATCH] FlattenedObjectVars: Only avoid relation traversing... ...if customvar_flat isn't being selected and it is guaranteed that ipl-orm will outsource the condition to a subquery. fixes #1020 --- library/Icingadb/Model/Behavior/FlattenedObjectVars.php | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/library/Icingadb/Model/Behavior/FlattenedObjectVars.php b/library/Icingadb/Model/Behavior/FlattenedObjectVars.php index 8b110e072..a200256cc 100644 --- a/library/Icingadb/Model/Behavior/FlattenedObjectVars.php +++ b/library/Icingadb/Model/Behavior/FlattenedObjectVars.php @@ -37,6 +37,14 @@ public function rewriteCondition(Filter\Condition $condition, $relation = null) ->set('columnPath', $relation . $column) ->set('relationPath', substr($relation, 0, -1)); + if (isset($this->query->getWith()[substr($relation, 0, -1)])) { + // In case customvar_flat is being selected, the FilterProcessor will not try to optimize the condition. + // So we can prepare the condition here and still let CustomvarFlat's behavior do the rest. + $condition->metaData()->set('columnName', $relation . $column); + + return $condition; + } + // 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.