You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by "V.A, Chandan" <ch...@sap.com> on 2014/11/01 08:28:09 UTC
RE: Serious bug in JPA visitor
Hi Giacomo,
The issue is now fixed. Please refer to JIRA issue - https://issues.apache.org/jira/browse/OLINGO-478
Thanks
Kind Regards
Chandan
-----Original Message-----
From: Kobler-Morris, Sven [mailto:sven.kobler-morris@sap.com]
Sent: Friday, October 31, 2014 5:10 PM
To: dev@olingo.apache.org
Subject: RE: Serious bug in JPA visitor
Hello Chandan,
Ok, this will also be good if SQL somehow has different operator precedence as OData (now, or in future ODatas versions)
Regards,
Sven
-----Original Message-----
From: V.A, Chandan [mailto:chandan.v.a@sap.com]
Sent: Freitag, 31. Oktober 2014 12:20
To: dev@olingo.apache.org
Subject: RE: Serious bug in JPA visitor
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:sven.kobler-morris@sap.com]
Sent: Friday, October 31, 2014 4:21 PM
To: dev@olingo.apache.org
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:chandan.v.a@sap.com]
Sent: Freitag, 31. Oktober 2014 11:22
To: dev@olingo.apache.org
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:sven.kobler-morris@sap.com]
Sent: Friday, October 31, 2014 2:24 PM
To: dev@olingo.apache.org
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:giacomo@pati.ch]
Sent: Freitag, 31. Oktober 2014 08:41
To: dev@olingo.apache.org
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
RE: Serious bug in JPA visitor
Posted by Giacomo Pati <gi...@pati.ch>.
Hi Chandan
Many thanks for this quick fix.
My next question would be, given its severity, whether this should make it
into the 2.0.1 release?
Ciao
On Nov 1, 2014 8:29 AM, "V.A, Chandan" <ch...@sap.com> wrote:
> Hi Giacomo,
> The issue is now fixed. Please refer to JIRA issue -
> https://issues.apache.org/jira/browse/OLINGO-478
>
> Thanks
> Kind Regards
> Chandan
>
> -----Original Message-----
> From: Kobler-Morris, Sven [mailto:sven.kobler-morris@sap.com]
> Sent: Friday, October 31, 2014 5:10 PM
> To: dev@olingo.apache.org
> Subject: RE: Serious bug in JPA visitor
>
> Hello Chandan,
>
> Ok, this will also be good if SQL somehow has different operator
> precedence as OData (now, or in future ODatas versions)
>
> Regards,
> Sven
>
> -----Original Message-----
> From: V.A, Chandan [mailto:chandan.v.a@sap.com]
> Sent: Freitag, 31. Oktober 2014 12:20
> To: dev@olingo.apache.org
> Subject: RE: Serious bug in JPA visitor
>
> 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:sven.kobler-morris@sap.com]
> Sent: Friday, October 31, 2014 4:21 PM
> To: dev@olingo.apache.org
> 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:chandan.v.a@sap.com]
> Sent: Freitag, 31. Oktober 2014 11:22
> To: dev@olingo.apache.org
> 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:sven.kobler-morris@sap.com]
> Sent: Friday, October 31, 2014 2:24 PM
> To: dev@olingo.apache.org
> 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:giacomo@pati.ch]
> Sent: Freitag, 31. Oktober 2014 08:41
> To: dev@olingo.apache.org
> 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
>