RHS path support (Ad Hoc JOIN)?

[wwadge]

Hi,

Is it possible to have an expression like employee.company_id == company.id ?

i.e. having a path on both sides of the expression?

[vineey]

Are you referring to join statement between two tables? sorry this kind of statement is not supported yet but a milestone. It would not be part of the rql filter expression.

In our practice, we define the table relationship in the backend by providing a JOIN PATH MAP such as
the code below. These must be annotated with jpa associations(ManyToOne, OneToMany,...).

Map<Path, EntityPath> JOIN_PATH = ImmutableMap.<Path, EntityPath>.builder()
         .put(QEmployee.employee.company, QCompany.company)
         .build();

This will be part of 1.1.0 release in the future, tentatively on end of June or early July this year.
This May, the priority is supporting querydsl v4.x.x as simultaneous 2.0.0 release which requires migration of the current 1.0.0 release which supports 3.x.x.

Along with these, I will verify if another version, which supports arbitrary join columns , could be implemented in a way like the code below.

Map<Path, Path> JOIN_PATH = ImmutableMap.<Path, EntityPath>.builder()
         .put(QEmployee.employee.companyId, QCompany.company.id)
         .build();

This is fully supported by the latest hibernate version (5.x) and of course querydsl v4.x.x, thus this version of join statement could be part of rsql-queyrdsl v.2.x.x.RELEASE. Not sure yet if we can backport this to querydsl v3.x.x, hence rql-querydsl v1.x.x.RELEASE

[vineey]

@wwadge If you want to contribute, please let me know. Any help is greatly appreciated, and it will be posted in the documentation and release notes. We can discuss the implementation plans and decide how we can divide and assign the tasks.

Meanwhile, please feel free to explore the code you have forked. Thanks.

[wwadge]

I would like to contribute. I was thinking something along these lines -- it creates a correct predicate at least. Wouldn't that work?

 @Override
    public BooleanExpression evaluate(BooleanPath path, ComparisonNode comparisonNode, QuerydslFilterParam param) {
        Object arg = comparisonNode.getArguments().get(0);

        ComparisonOperator operator = comparisonNode.getOperator();

        if (arg != null) {
            Path rhsPath = param.getMapping().get(arg);

            if (EQUAL.equals(operator)) {
                return path.eq(rhsPath);
            }

            if (NOT_EQUAL.equals(operator)) {
                return path.ne(rhsPath).or(path.isNull());
            }
        }


        Boolean barg = convertToBoolean(comparisonNode);


        if (barg == null) {
            return path.isNull();
        }


        if (EQUAL.equals(operator)) {
            return path.eq(barg);
        }

        if (NOT_EQUAL.equals(operator)) {
            return path.ne(barg).or(path.isNull());
        }

        throw new UnsupportedRqlOperatorException(comparisonNode, path.getClass());
    }

I will probably also migrate to querydsl 4.x though I see there's already a branch named feature/querydsl4

[vineey]

@wwadge Awesome! Your idea just make sense, though we still have to validate explicitly if the paths(columns) involve have the same data type. This kind of feature can support dynamic reporting that doesn't involve predefined table relationship. To support this we should provide a way to discover the tables involved in this filter expression and automatically include them in the querydsl FROM clause. Let me think about this one, will analyze the impact and possible issues that could arise. You can also provide a working POC if you want.

As for this project, my original plan is to support predefined table relationship, which I said last time. Using this predefined relationship via joined path map and defining the fields to be retrieved via the select field map, the querydsl JOIN clause is built base on these parameters. So basically, I don't use the WHERE clause for relationship. Also in this way, the backend can control which fields and relationships are allowed for the client to be used, for security purposes.

[vineey]

@wwadge If you want to contribute to 2.0.0.RELEASE, you can start the migration of the code from querydsl v3.x.x to querydsl v4.x.x on the feature/querydsl4 branch. Later, just send me a pull request and I will review it. What do you say?

[wwadge]

ok let me update to querydsl4 first and submit a PR

[wwadge]

PR submitted: #16

[vineey]

@wwadge hibernate 5.1 now supports ad hoc join on entities with no explicit association mapping.
Please refer to this link,

http://in.relation.to/2016/02/10/hibernate-orm-510-final-release/

http://blog.anthavio.net/2016/03/join-unrelated-entities-in-jpa.html

This can be taken advantage by rsql-querydsl 2.x.x.RELEASE. But I'm thinking instead of mixing it with rsql filter expression which should just contains lhs path and rhs values, we could provide a separate kind rsql expression just for joining two tables. This will add modularity and clean code since this requires a total different implementation.

Also, in this way, we could still provide a HashMap that would define the allowable ad hoc join columns between tables, thus the backend can still have the restrictions. On the other hand, not defining the HashMap means allowing the client to join any columns between known tables.

What do you say?

[vineey]

With regards to 1.x.x.RELEASE, a different approach needs to be taken. Possibly won't support it since hibernate used by querydsl 3.x.x doesn't support it directly. Though there is still a way to do it, via subquery. A subquery is the only way to support ad hoc table relationship using an exist expression in the main query WHERE clause and the ad hoc join defined in the subquery WHERE clause.