I noticed that FetchPropertyFunction contains all the necessary methods to build a complete query, so I created an example code for this that might inspire others.

I believe this goes against the "nature" of the API -> to compose expressions via the "composition over inheritance" pattern.

This example code doesn't work for me - there is something wrong when processing modifier %ex and it cannot handle even a simple column name:

Ideally, please add what's wrong to your issues.

The documentation has a bug, Nextras 5.0 should be using $expression->getArgsForExpansion(). I'm fixing this :)

Thx for repoting!

Ah, my mistake, I obviously got a little confused. The problem was that the %ex modifier requires a parameter in a different format.

After calling this:

$expression = $helper->processExpression($builder, 'devices->model', $aggregator);

You will get in $expression->args[0] the following value:

Nextras\Dbal\Platforms\Data\Fqn('devices_any', 'model')

Which will throw an exception Modifier %ex expects value to be array, Nextras\Dbal\Platforms\Data\Fqn given. if you use it for the %ex modifier.

What you need is this:

['%column', Nextras\Dbal\Platforms\Data\Fqn('devices_any', 'model')]

Which is what the $expression->getArgsForExpansion() method you mentioned returns and then it works correctly. It is also necessary to pass the joins property from $expression to the new DbalExpressionResult instance. So thank you for the clarification :-)

But I have another question: Why don't you automatically pass all properties from $expression to the new DbalExpressionResult instance? It seems to me that you basically always want to preserve generated context, because you don't know what was added to the query builder. Then it might be useful to create a method like append() that would clone DbalExpressionResult, just with a different expression and args parameters. Or is it just not that common a scenario or it just not make sense for another reason?

That's exactly what the docs mention