Christian Beikov

Hi, unfortunately there is currently no "real" workaround for this yet as filters are applied as conditions to the main query, whereas this requires applying filters into the subquery. We...

What do you think about merging the parser into core-impl? I don't think there is a real need to have the parser separately anyway. Merging would make all of this...

It is actually a separate project since the beginning. The only reason for needing it as separate project is for modules like entity-view-impl etc. which do parsing at boot time,...

>Trying to build the project locally to understand the issues in the tests, but failing Don't worry about that, you simply can't statically refer to the javax class as that...

Actually I think we should do this in _core_ already instead. Entity views should not have to change anything and only the final JPQL output should show the transformed expression.

The implementation should be pretty simple, just run the PathTargetResolvingExpressionVisitor on the expression and throw an error if the target type is not a subtype of the subviews entity type.

Hey there, it's probably a bug in the integration, since we need to extract and transform SQL to render CTEs, I guess that we didn't think about filters too much....

We can introduce that method, but I think nesting windows will complicate things.

Also implement proper `fromClause` propagation throughout the process. Currently the wrong clause dependency is registered on a newly generated join node.

https://github.com/Blazebit/blaze-persistence/pull/1383 will add support for most of these functions. The only ones left now are: * Date trunc functions * Date add functions * Date extract functions