Proper way to create a duplicate Expression object

[sivaraam]

I recently faced a situation where I needed to set the same criteria expression in all the SELECTs in a UNION query. Though the criteria is same, I would want distinct objects that represent the same criteria i.e., changing the criteria in one of the SELECT queries should not affect the criteria in the other SELECT queries. Let me demonstrate what I was trying to achieve:

		Select selectStatement = (Select) CCJSqlParserUtil.parse(
                "SELECT id FROM table1 UNION SELECT id FROM table2"
        );
        Expression criteriaExpr = CCJSqlParserUtil.parseCondExpression("NAME LIKE '%M%'");

        selectStatement.getSelectBody().accept(new SelectVisitorAdapter() {
            @Override
            public void visit(PlainSelect plainSelect) {
                plainSelect.setWhere(criteriaExpr);
            }

            @Override
            public void visit(SetOperationList setOpList) {
                setOpList.getSelects().forEach(
                        selectBody -> selectBody.accept(this)
                );
            }
        });

The program properly sets the criteria for both the queries. But as it uses the same criteriaExpr object for both the queries in the UNION, changing the criteria in one of the queries also changes the criteria in the other query. This is an issue in my case.

One way to overcome this is by moving the creation of the criteriaExpr into the visit(PlainSelect plainSelect) method. But it has the limitation that there is no direct way to communicate to the caller, the case in which the criteria could not be parsed (i.e., when an JSQLParserException occurs) as the signature of the visit method cannot be changed.

Coming to the question, is there a way to create a clone of the creteriaExpr without having to parse the expression again so that a unique object can be assigned to all the queries in the UNION?

[wumpz]

Not yet. The proper way would-be to parse the string again.

[sivaraam]

Ok. Thanks. Looks I would have to work around with communicating the parse exception, for now 🙂

[wumpz]

The the true right way would be to implement a CopyVisitor for this. Besides, before I started maintaining the project the logic to traverse the object tree was externalized within the Visitor interfaces or classes. Til now I could not decide where to put it best (extern or class intern).

[wumpz]

With my proposal #901 this would be more simple.

[wumpz]

Do you have some comments regarding #901?

[sivaraam]

For the record, I've replied in #901 with my opinion.

[sivaraam]

Also, sorry that I didn't add my comments earlier! Forgot about the suggested API change. My bad 🤦‍♂.

Feel free to ping me the next time if you feel that I could provide some useful input.

[wumpz]

Never mind. Could I close this issue.

[sivaraam]

Sure.