Hello Sven, I will stick to the worst case scenario and enclose every node of binary expression within a parenthesis.
Sample JPQL statement - SELECT E1 FROM Customer E1 WHERE (((E1.id = 100) OR (E1.id = 200)) AND (E1.name > 'Bob Bryan')) ORDER BY E1.id for the OData Filter string - http://localhost:8080/olingo-odata2-jpa-processor-ref-web/SalesOrderProcessing.svc/Customers?$filter=(Id eq 100 or Id eq 200) and Name gt 'Bob Bryan' Thanks Kind Regards Chandan -----Original Message----- From: Kobler-Morris, Sven [mailto:[email protected]] Sent: Friday, October 31, 2014 4:21 PM To: [email protected] Subject: RE: Serious bug in JPA visitor Hello Chandan, the parenthesis are not in the expression tree and can unfortunately not be determined afterwards. The parenthesis are just reflected in the tree within the node hierarchy. So each node forms a kind of parenthesis. In the worst case I think the SQL clause will contain parenthesis for all nodes. E.g. like the test visitor dies with the "{}". Regards, Sven -----Original Message----- From: V.A, Chandan [mailto:[email protected]] Sent: Freitag, 31. Oktober 2014 11:22 To: [email protected] Subject: RE: Serious bug in JPA visitor Hello Sven, If I am not wrong, if we are evaluating the expression tree, the way it is demonstrated in Olingo core reference scenario then the order of precedence will work. Because here we evaluate the expression tree by navigating through the nodes of the tree as they appear and evaluate them. However if now I need to use the expression tree to build a JPQL Expression string then the expression tree does not provide information on the availability of parenthesis and hence the final JPQL statement that gets built loses out on parenthesis. Is there any way we could get the availability of parenthesis in the filter string via expression tree so that the same can be added to the JPQL expression string? Thanks Kind Regards Chandan -----Original Message----- From: Kobler-Morris, Sven [mailto:[email protected]] Sent: Friday, October 31, 2014 2:24 PM To: [email protected] Subject: RE: Serious bug in JPA visitor Hello Chandan, seems a bug in the JPA processor or more in the JPAs-Visitor. The expression tree serialized with a test visitor shows that the parenthesis are correctly evaluated. I added a test to file "TestParser.java" @Test public void testAndOr() { //A GetPTF("(SoId eq 2 or SoId eq 3 or SoId eq 4) and Delivered eq true") .aSerialized("{{{{SoId eq 2} or {SoId eq 3}} or {SoId eq 4}} and {Delivered eq true}}"); //B GetPTF("SoId eq 2 or SoId eq 3 or SoId eq 4 and Delivered eq true") .aSerialized("{{{SoId eq 2} or {SoId eq 3}} or {{SoId eq 4} and {Delivered eq true}}}"); } It shows that in A the "or's" in the pathentesis are gouped together. Where as in B the "and" is first grouped because and has a higher priority. Regards, Sven -----Original Message----- From: Giacomo Pati [mailto:[email protected]] Sent: Freitag, 31. Oktober 2014 08:41 To: [email protected] Subject: Serious bug in FilterParser Hi all We recently run into a serious issue regarding filters and I want someone of you to double check. When you run the following query against a deployed olingo-odata2-jpa-processor-ref-web like http://localhost:8080/SalesOrderProcessing.svc/SalesOrderItems?$filter=(SoId eq 2 or SoId eq 3 or SoId eq 4) and Delivered eq true one would expect to see only Entities with a property Delivered == true but this is not the case. I've also run a quick junit test against FilterParserImpl with such a query using an ExpressionVisitor and figured that it seems that the parenthesis are not respected which would reduce the query to "SoId eq 2 or SoId eq 3 or SoId eq 4 and Delivered eq true" and it seems that is actually what happens. Anyone else? Ciao -- Giacomo
