11
11
use ipl \Orm \Contract \QueryAwareBehavior ;
12
12
use ipl \Orm \Contract \RewriteColumnBehavior ;
13
13
use ipl \Orm \Query ;
14
- use ipl \Stdlib \Data ;
15
14
use ipl \Stdlib \Filter ;
16
15
17
16
class FlattenedObjectVars implements RewriteColumnBehavior, QueryAwareBehavior
@@ -42,22 +41,11 @@ public function rewriteCondition(Filter\Condition $condition, $relation = null)
42
41
// Previously, this behavior transformed a single condition to an ALL chain and hence the semantics
43
42
// of the level changed, since the FilterProcessor interpreted the conditions separately from there on.
44
43
// To not change the semantics of the condition it is required to delay the transformation of the condition
45
- // until the subquery is created. Though, since the FilterProcessor only applies behaviors once, this
46
- // hack is required. (The entire filter, metadata and optimization is total garbage.)
47
- $ oldMetaData = $ condition ->metaData ();
48
- $ metaDataProperty = (new \ReflectionClass ($ condition ))->getProperty ('metaData ' );
49
- $ metaDataProperty ->setAccessible (true );
50
- $ metaDataProperty ->setValue ($ condition , new class () extends Data {
51
- public function set ($ name , $ value )
52
- {
53
- if ($ name === 'behaviorsApplied ' ) {
54
- return $ this ;
55
- }
56
-
57
- return parent ::set ($ name , $ value );
58
- }
59
- });
60
- $ condition ->metaData ()->merge ($ oldMetaData );
44
+ // until the subquery is created. Though, since this is about custom variables, and such can contain dots,
45
+ // the FilterProcessor then continues traversing the parts of the column's path, which then would include
46
+ // the dot-separated parts of the custom variable name. To prevent this, we have to signal that what we
47
+ // return a replacement here, that should be used as-is and not processed further.
48
+ $ condition ->metaData ()->set ('forceResolved ' , true );
61
49
62
50
// But to make it even worse: If we do that, (not transforming the condition) the FilterProcessor sees
63
51
// multiple conditions as targeting different columns, as it doesn't know that the *columns* are in fact
@@ -66,6 +54,8 @@ public function set($name, $value)
66
54
// the condition refer to a different column, which is totally irrelevant, but since it's always the same
67
55
// column, the FilterProcessor won't attempt to combine the conditions. The literal icing on the cake.
68
56
$ condition ->setColumn ('always_the_same_but_totally_irrelevant ' );
57
+
58
+ return $ condition ;
69
59
}
70
60
}
71
61
0 commit comments