You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@olingo.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2014/02/11 17:31:27 UTC
Re: How to use Olingo Parser directly
Hi
Can we expect the filter visitor mechanism working in the future Olingo
releases, example, the ones supporting OData 4 ? I reckon the $filter
mechanism is supported in the backward-compatible manner, but would like
to check as we've gone ahead with doing some work in CXF
Thanks, Sergey
>>
>> On Sat, Dec 7, 2013 at 2:32 AM, Sergey Beryozkin
>> <sb...@gmail.com>wrote:
>>
>>> Hi Stephan
>>>
>>> On 06/12/13 14:17, Klevenz, Stephan wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> try this:
>>>>
>>>> FilterExpression filterExpression = UriParser.parseFilter(null,
>>>> null,
>>>> "Name eq 'Milk' and Price lt '2.55M'");
>>>>
>>>> The metadata objects are optional and can be null. If they are set then
>>>> the parser will validate the filter.
>>>>
>>>> And you'll find a tutorial about how to proceed with the expression
>>>> here:
>>>>
>>>>
>>>>
>>>> http://olingo.incubator.apache.org/doc/tutorials/
>>>> Olingo_Tutorial_AdvancedRe
>>>> ad_FilterVisitor.html
>>>>
>>>>
>>>> Let us know if you require more information.
>>>>
>>>> I think this is exactly what we need, thanks a mill, how did I miss
>>>> that
>>> link ? :-)
>>>
>>> Cheers, Sergey
>>>
>>>
>>> Regards,
>>>> Stephan
>>>>
>>>>
>>>>
>>>> On 06.12.13 11:28, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>>>>
>>>> Hi
>>>>>
>>>>> This may be a user-level question but I haven't been able to find a
>>>>> users forum.
>>>>>
>>>>> I've checked several Olingo titorials, they are very good and detailed
>>>>> at explaining how custom extensions and providers can be registered
>>>>> with
>>>>> Olingo core for Olingo to drive the proper exposition of the data.
>>>>>
>>>>> What I'd like to understand, and I think this can be of interest to
>>>>> many
>>>>> users planning to do some work with the help of Olingo, is how to get
>>>>> Olingo Parser and other relevant API used directly.
>>>>>
>>>>> For example, suppose I write a standalone JAX-RS application which has
>>>>> no OData support yet:
>>>>>
>>>>> @GET
>>>>> @Path("/books/{id}")
>>>>> public Book getBookById(@PathParam("id") String id) {
>>>>> //
>>>>> }
>>>>>
>>>>> Now I'd like to provide the way for users to search for Books. And I'd
>>>>> like to try OData, so I add another method to my JAX-RS resource:
>>>>>
>>>>> @GET
>>>>> @Path("/books")
>>>>> public List<Book> findBooks(@QueryParam("$filter") String odataQuery)
>>>>> {
>>>>>
>>>>> }
>>>>>
>>>>> In order to implement this method I'd like to know how I can use
>>>>> OLingo
>>>>> parser to parse a captured $filter expression and how to introspect
>>>>> the
>>>>> parser output in order to build an actual DB query, lets say SQL one.
>>>>>
>>>>> Perhaps a tutorial can be added ?
>>>>> For example, lets say a findBooks() Method captures a
>>>>>
>>>>> "Name eq 'Milk' and Price lt '2.55M'"
>>>>>
>>>>> expression. How would one go and convert it to SQL with the help of
>>>>> Olingo withing the *existing* JAX-RS application ?
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Peter Kelley
>
Re: How to use Olingo Parser directly
Posted by "Bolz, Michael" <mi...@sap.com>.
I forgot to add two links to the documentation for $filter:
OData v2: http://www.odata.org/documentation/odata-v2-documentation/uri-conventions/#45_Filter_System_Query_Option_filter
OData v4: http://docs.oasis-open.org/odata/odata/v4.0/cos01/part2-url-conventions/odata-v4.0-cos01-part2-url-conventions.html#_Toc372793792
On 12 Feb 2014, at 06:12, Bolz, Michael <mi...@sap.com> wrote:
> Hi Sergey,
>
> The $filter mechanism in Odata 4 should work like in Odata 2.
> At least the basic filter expressions (logic and arithmetic like Œeq¹,
> Œadd¹, Š).
> I think the functions have changed a little bit with naming and syntax.
>
> But I guess your question points more to the implementation in Olingo
> library for Odata 4.
> I think here we can give Sven a better answer.
> @Sven: Can you give an answer here?
>
> Kind regards,
> Michael
>
>
>
>
> On 11/02/14 17:31, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>
>> Hi
>>
>> Can we expect the filter visitor mechanism working in the future Olingo
>> releases, example, the ones supporting OData 4 ? I reckon the $filter
>> mechanism is supported in the backward-compatible manner, but would like
>> to check as we've gone ahead with doing some work in CXF
>>
>> Thanks, Sergey
>>>>
Re: [OT] Is OData open enough ?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ralf
On 13/02/14 17:26, Handl, Ralf wrote:
> Hi Sergey,
>
> OData already supports this using the HTTP headers odata.version and odata.maxversion, see http://docs.oasis-open.org/odata/odata/v4.0/cos01/part1-protocol/odata-v4.0-cos01-part1-protocol.html#_The_OData-Version_Header.
>
> A server that only accepts the OData query language but does not support OData JSON can respond with Content-Type:application/json and its own JSON dialect as long as it doesn't claim to be an OData service by also including an odata-version response header.
>
> A server that supports both OData JSON and some other JSON dialect can serve OData clients as well as non-OData clients: the OData clients SHOULD include an odata-version or odata-maxversion header in their request.
>
> A server that supports only OData JSON will respond with OData JSON, which after all is just JSON, so non-OData clients can digest it with JSON.parse or something similar.
>
> And OData JSON in its "minimal metadata" or "no metadata" flavor looks pretty much like what someone would hand-craft: if a book has an id, the JSON object for a book will have an id name-value pair. Not much choice there. If you want to return a list of books, that's essentially an array of book objects. Given that an array as the root object of a JSON document is vulnerable to attacks (http://haacked.com/archive/2009/06/25/json-hijacking.aspx/), format designers are well advised to make the array a name-value pair of a wrapping plain object. Now the only design choice left is how to name the array. OData opted for "value", which seems pretty neutral.
>
> Does that cover your use case?
>
It really does; it's perfect,
Thanks for the clarifications
Cheers, Sergey
> Thanks!
> --Ralf
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Thursday, 13. February 2014 17:43
> To: dev@olingo.incubator.apache.org
> Subject: [OT] Is OData open enough ?
>
> Hi All,
>
> Now that CXF supporta OData $filter expressions with the help of Olingo,
> I've started wondering, after checking OData 4.0, are we really going
> for supporting 'OData the query language' to let CXF developers enhance
> the search capabilities of their existing applications not specifically
> written with 'OData the protocol' in mind or do we basically add one
> more CXF search extension (fine with me per se) which will let users
> 'borrow' the OData $filter syntax ?
>
> For example, suppose we have a service returning a collection of Books -
> this is all formatted in whatever format supported by the application,
> example, "application/xml":
>
> GET /mybooks
> Accept: application/xml
>
> <Books>
> <Book id="1"/>
> <Book id="2"/>
> </Books>
>
> Now the users liked a $filter syntax and would like support the
> filtering of books by id,
>
> GET /mybooks$filter=id%20eq%201
> Accept: application/xml
>
> returns
>
> <Books>
> <Book id="1"/>
> </Books>
>
> ; the same for application/json
>
> may be I've got confused but it appears to me that it is really
> supported by the formal document ?
> Example,
>
> GET /mybooks$filter=id%20eq%201
> Accept: application/json
>
> is presumably expected to return JSON formatted per the OData rules *only* ?
>
> I'd really prefer the document:
> - making some 'space' between the actual query language and the protocol
> itself so that people can apply the OData the query language to their
> existing applications without having to re-write them to be OData centric
> - this might be supported via $format query, but I'm not sure, I;d
> rather see something like
>
> GET /mybooks$filter=id%20eq%201
> Accept: application/odata+json
>
> indicating that OData-centric JSON payload is expected back.
>
> Simply
> Accept: application/json;format=odata
>
> would probably do too
>
> is it already possible ?
>
> IMHO, the lesser the binding of the language to the protocol is the
> better it is for the adopters
>
> Thanks, Sergey
>
>
>
>
>
>
>
RE: [OT] Is OData open enough ?
Posted by "Handl, Ralf" <ra...@sap.com>.
Hi Sergey,
OData already supports this using the HTTP headers odata.version and odata.maxversion, see http://docs.oasis-open.org/odata/odata/v4.0/cos01/part1-protocol/odata-v4.0-cos01-part1-protocol.html#_The_OData-Version_Header.
A server that only accepts the OData query language but does not support OData JSON can respond with Content-Type:application/json and its own JSON dialect as long as it doesn't claim to be an OData service by also including an odata-version response header.
A server that supports both OData JSON and some other JSON dialect can serve OData clients as well as non-OData clients: the OData clients SHOULD include an odata-version or odata-maxversion header in their request.
A server that supports only OData JSON will respond with OData JSON, which after all is just JSON, so non-OData clients can digest it with JSON.parse or something similar.
And OData JSON in its "minimal metadata" or "no metadata" flavor looks pretty much like what someone would hand-craft: if a book has an id, the JSON object for a book will have an id name-value pair. Not much choice there. If you want to return a list of books, that's essentially an array of book objects. Given that an array as the root object of a JSON document is vulnerable to attacks (http://haacked.com/archive/2009/06/25/json-hijacking.aspx/), format designers are well advised to make the array a name-value pair of a wrapping plain object. Now the only design choice left is how to name the array. OData opted for "value", which seems pretty neutral.
Does that cover your use case?
Thanks!
--Ralf
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Thursday, 13. February 2014 17:43
To: dev@olingo.incubator.apache.org
Subject: [OT] Is OData open enough ?
Hi All,
Now that CXF supporta OData $filter expressions with the help of Olingo,
I've started wondering, after checking OData 4.0, are we really going
for supporting 'OData the query language' to let CXF developers enhance
the search capabilities of their existing applications not specifically
written with 'OData the protocol' in mind or do we basically add one
more CXF search extension (fine with me per se) which will let users
'borrow' the OData $filter syntax ?
For example, suppose we have a service returning a collection of Books -
this is all formatted in whatever format supported by the application,
example, "application/xml":
GET /mybooks
Accept: application/xml
<Books>
<Book id="1"/>
<Book id="2"/>
</Books>
Now the users liked a $filter syntax and would like support the
filtering of books by id,
GET /mybooks$filter=id%20eq%201
Accept: application/xml
returns
<Books>
<Book id="1"/>
</Books>
; the same for application/json
may be I've got confused but it appears to me that it is really
supported by the formal document ?
Example,
GET /mybooks$filter=id%20eq%201
Accept: application/json
is presumably expected to return JSON formatted per the OData rules *only* ?
I'd really prefer the document:
- making some 'space' between the actual query language and the protocol
itself so that people can apply the OData the query language to their
existing applications without having to re-write them to be OData centric
- this might be supported via $format query, but I'm not sure, I;d
rather see something like
GET /mybooks$filter=id%20eq%201
Accept: application/odata+json
indicating that OData-centric JSON payload is expected back.
Simply
Accept: application/json;format=odata
would probably do too
is it already possible ?
IMHO, the lesser the binding of the language to the protocol is the
better it is for the adopters
Thanks, Sergey
[OT] Is OData open enough ?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi All,
Now that CXF supporta OData $filter expressions with the help of Olingo,
I've started wondering, after checking OData 4.0, are we really going
for supporting 'OData the query language' to let CXF developers enhance
the search capabilities of their existing applications not specifically
written with 'OData the protocol' in mind or do we basically add one
more CXF search extension (fine with me per se) which will let users
'borrow' the OData $filter syntax ?
For example, suppose we have a service returning a collection of Books -
this is all formatted in whatever format supported by the application,
example, "application/xml":
GET /mybooks
Accept: application/xml
<Books>
<Book id="1"/>
<Book id="2"/>
</Books>
Now the users liked a $filter syntax and would like support the
filtering of books by id,
GET /mybooks$filter=id%20eq%201
Accept: application/xml
returns
<Books>
<Book id="1"/>
</Books>
; the same for application/json
may be I've got confused but it appears to me that it is really
supported by the formal document ?
Example,
GET /mybooks$filter=id%20eq%201
Accept: application/json
is presumably expected to return JSON formatted per the OData rules *only* ?
I'd really prefer the document:
- making some 'space' between the actual query language and the protocol
itself so that people can apply the OData the query language to their
existing applications without having to re-write them to be OData centric
- this might be supported via $format query, but I'm not sure, I;d
rather see something like
GET /mybooks$filter=id%20eq%201
Accept: application/odata+json
indicating that OData-centric JSON payload is expected back.
Simply
Accept: application/json;format=odata
would probably do too
is it already possible ?
IMHO, the lesser the binding of the language to the protocol is the
better it is for the adopters
Thanks, Sergey
RE: How to use Olingo Parser directly
Posted by "Kobler-Morris, Sven" <sv...@sap.com>.
Hallo Sergey,
the visitor pattern of the filter /order by expression is more of less the same,
there are just some new methods and operators and the path segments for
member are expressed differently. Thinks it will be possible to call the filter visitor directly.
Regards,
Sven
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Mittwoch, 12. Februar 2014 11:29
To: dev@olingo.incubator.apache.org
Subject: Re: How to use Olingo Parser directly
Specifically, we have a code where
org.apache.olingo.odata2.api.uri.expression.ExpressionVisitor is
implemented and the implementing class is getting the callbacks.
We parse it a $filter expression and getting the callbacks and translate
them accordingly.
Here is a pseudo code:
String searchExpression = getItFrom$filter();
final FilterExpression expression = new
FilterParserImpl(null).parseFilterString(searchExpression);
final ExpressionVisitor visitor = new CustomExpressionVisitor();
expression.accept(visitor);
I am a bit confused by a reference to UriInfo: I guess UriInfo is more
of the alternative, right, and would expect the filter visitor mechanism
still working even though it is very reasonable to expect that migration
effort might be needed.
Cheers, Sergey
On 12/02/14 10:15, Sergey Beryozkin wrote:
> Hi Sven, Michael. All
>
> So with Olingo 1.1.0 we have the code as shown at [1] working.
>
> Am I reading it that with the Olingo trunk implementing 4.0 Filter
> parser a different mechanism will be needed ?
>
> If so, we'd appreciate having [1] updated accordingly
>
> Thanks, Sergey
>
> [1]
> http://olingo.incubator.apache.org/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.html
>
> On 12/02/14 08:40, Kobler-Morris, Sven wrote:
>> Hello Sergey,
>>
>> the ODATA 4.0 Filter parser is combined with the URI parser in order
>> to parse the URI as a whole.
>>
>> The filter expression tree itself is more or less the same as in ODATA
>> 2.0 an can be accessed through an
>> UriInfo object.
>>
>> The API for the URI parser is in package
>> "org.apache.olingo.odata4.producer.api.uri"
>> whereas the filter part is in
>> "org.apache.olingo.odata4.producer.api.uri.queryoption.expression"
>>
>> Kind regards,
>> Sven
>> -----Original Message-----
>> From: Bolz, Michael
>> Sent: Mittwoch, 12. Februar 2014 06:12
>> To: dev@olingo.incubator.apache.org; Kobler-Morris, Sven
>> Subject: Re: How to use Olingo Parser directly
>>
>> * PGP Signature not checked
>>
>> Hi Sergey,
>>
>> The $filter mechanism in Odata 4 should work like in Odata 2.
>> At least the basic filter expressions (logic and arithmetic like Œeq¹,
>> Œadd¹, Š).
>> I think the functions have changed a little bit with naming and syntax.
>>
>> But I guess your question points more to the implementation in Olingo
>> library for Odata 4.
>> I think here we can give Sven a better answer.
>> @Sven: Can you give an answer here?
>>
>> Kind regards,
>> Michael
>>
>>
>>
>>
>> On 11/02/14 17:31, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Can we expect the filter visitor mechanism working in the future Olingo
>>> releases, example, the ones supporting OData 4 ? I reckon the $filter
>>> mechanism is supported in the backward-compatible manner, but would like
>>> to check as we've gone ahead with doing some work in CXF
>>>
>>> Thanks, Sergey
>>>>>
>>
>> * Signature checking is off by policy
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: How to use Olingo Parser directly
Posted by Sergey Beryozkin <sb...@gmail.com>.
Specifically, we have a code where
org.apache.olingo.odata2.api.uri.expression.ExpressionVisitor is
implemented and the implementing class is getting the callbacks.
We parse it a $filter expression and getting the callbacks and translate
them accordingly.
Here is a pseudo code:
String searchExpression = getItFrom$filter();
final FilterExpression expression = new
FilterParserImpl(null).parseFilterString(searchExpression);
final ExpressionVisitor visitor = new CustomExpressionVisitor();
expression.accept(visitor);
I am a bit confused by a reference to UriInfo: I guess UriInfo is more
of the alternative, right, and would expect the filter visitor mechanism
still working even though it is very reasonable to expect that migration
effort might be needed.
Cheers, Sergey
On 12/02/14 10:15, Sergey Beryozkin wrote:
> Hi Sven, Michael. All
>
> So with Olingo 1.1.0 we have the code as shown at [1] working.
>
> Am I reading it that with the Olingo trunk implementing 4.0 Filter
> parser a different mechanism will be needed ?
>
> If so, we'd appreciate having [1] updated accordingly
>
> Thanks, Sergey
>
> [1]
> http://olingo.incubator.apache.org/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.html
>
> On 12/02/14 08:40, Kobler-Morris, Sven wrote:
>> Hello Sergey,
>>
>> the ODATA 4.0 Filter parser is combined with the URI parser in order
>> to parse the URI as a whole.
>>
>> The filter expression tree itself is more or less the same as in ODATA
>> 2.0 an can be accessed through an
>> UriInfo object.
>>
>> The API for the URI parser is in package
>> "org.apache.olingo.odata4.producer.api.uri"
>> whereas the filter part is in
>> "org.apache.olingo.odata4.producer.api.uri.queryoption.expression"
>>
>> Kind regards,
>> Sven
>> -----Original Message-----
>> From: Bolz, Michael
>> Sent: Mittwoch, 12. Februar 2014 06:12
>> To: dev@olingo.incubator.apache.org; Kobler-Morris, Sven
>> Subject: Re: How to use Olingo Parser directly
>>
>> * PGP Signature not checked
>>
>> Hi Sergey,
>>
>> The $filter mechanism in Odata 4 should work like in Odata 2.
>> At least the basic filter expressions (logic and arithmetic like Œeq¹,
>> Œadd¹, Š).
>> I think the functions have changed a little bit with naming and syntax.
>>
>> But I guess your question points more to the implementation in Olingo
>> library for Odata 4.
>> I think here we can give Sven a better answer.
>> @Sven: Can you give an answer here?
>>
>> Kind regards,
>> Michael
>>
>>
>>
>>
>> On 11/02/14 17:31, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Can we expect the filter visitor mechanism working in the future Olingo
>>> releases, example, the ones supporting OData 4 ? I reckon the $filter
>>> mechanism is supported in the backward-compatible manner, but would like
>>> to check as we've gone ahead with doing some work in CXF
>>>
>>> Thanks, Sergey
>>>>>
>>
>> * Signature checking is off by policy
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: How to use Olingo Parser directly
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Sven, Michael. All
So with Olingo 1.1.0 we have the code as shown at [1] working.
Am I reading it that with the Olingo trunk implementing 4.0 Filter
parser a different mechanism will be needed ?
If so, we'd appreciate having [1] updated accordingly
Thanks, Sergey
[1]
http://olingo.incubator.apache.org/doc/tutorials/Olingo_Tutorial_AdvancedRead_FilterVisitor.html
On 12/02/14 08:40, Kobler-Morris, Sven wrote:
> Hello Sergey,
>
> the ODATA 4.0 Filter parser is combined with the URI parser in order to parse the URI as a whole.
>
> The filter expression tree itself is more or less the same as in ODATA 2.0 an can be accessed through an
> UriInfo object.
>
> The API for the URI parser is in package
> "org.apache.olingo.odata4.producer.api.uri"
> whereas the filter part is in
> "org.apache.olingo.odata4.producer.api.uri.queryoption.expression"
>
> Kind regards,
> Sven
> -----Original Message-----
> From: Bolz, Michael
> Sent: Mittwoch, 12. Februar 2014 06:12
> To: dev@olingo.incubator.apache.org; Kobler-Morris, Sven
> Subject: Re: How to use Olingo Parser directly
>
> * PGP Signature not checked
>
> Hi Sergey,
>
> The $filter mechanism in Odata 4 should work like in Odata 2.
> At least the basic filter expressions (logic and arithmetic like Œeq¹,
> Œadd¹, Š).
> I think the functions have changed a little bit with naming and syntax.
>
> But I guess your question points more to the implementation in Olingo
> library for Odata 4.
> I think here we can give Sven a better answer.
> @Sven: Can you give an answer here?
>
> Kind regards,
> Michael
>
>
>
>
> On 11/02/14 17:31, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>
>> Hi
>>
>> Can we expect the filter visitor mechanism working in the future Olingo
>> releases, example, the ones supporting OData 4 ? I reckon the $filter
>> mechanism is supported in the backward-compatible manner, but would like
>> to check as we've gone ahead with doing some work in CXF
>>
>> Thanks, Sergey
>>>>
>
> * Signature checking is off by policy
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
RE: How to use Olingo Parser directly
Posted by "Kobler-Morris, Sven" <sv...@sap.com>.
Hello Sergey,
the ODATA 4.0 Filter parser is combined with the URI parser in order to parse the URI as a whole.
The filter expression tree itself is more or less the same as in ODATA 2.0 an can be accessed through an
UriInfo object.
The API for the URI parser is in package
"org.apache.olingo.odata4.producer.api.uri"
whereas the filter part is in
"org.apache.olingo.odata4.producer.api.uri.queryoption.expression"
Kind regards,
Sven
-----Original Message-----
From: Bolz, Michael
Sent: Mittwoch, 12. Februar 2014 06:12
To: dev@olingo.incubator.apache.org; Kobler-Morris, Sven
Subject: Re: How to use Olingo Parser directly
* PGP Signature not checked
Hi Sergey,
The $filter mechanism in Odata 4 should work like in Odata 2.
At least the basic filter expressions (logic and arithmetic like Œeq¹,
Œadd¹, Š).
I think the functions have changed a little bit with naming and syntax.
But I guess your question points more to the implementation in Olingo
library for Odata 4.
I think here we can give Sven a better answer.
@Sven: Can you give an answer here?
Kind regards,
Michael
On 11/02/14 17:31, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>Hi
>
>Can we expect the filter visitor mechanism working in the future Olingo
>releases, example, the ones supporting OData 4 ? I reckon the $filter
>mechanism is supported in the backward-compatible manner, but would like
>to check as we've gone ahead with doing some work in CXF
>
>Thanks, Sergey
>>>
* Signature checking is off by policy
Re: How to use Olingo Parser directly
Posted by "Bolz, Michael" <mi...@sap.com>.
Hi Sergey,
The $filter mechanism in Odata 4 should work like in Odata 2.
At least the basic filter expressions (logic and arithmetic like eq¹,
add¹, ).
I think the functions have changed a little bit with naming and syntax.
But I guess your question points more to the implementation in Olingo
library for Odata 4.
I think here we can give Sven a better answer.
@Sven: Can you give an answer here?
Kind regards,
Michael
On 11/02/14 17:31, "Sergey Beryozkin" <sb...@gmail.com> wrote:
>Hi
>
>Can we expect the filter visitor mechanism working in the future Olingo
>releases, example, the ones supporting OData 4 ? I reckon the $filter
>mechanism is supported in the backward-compatible manner, but would like
>to check as we've gone ahead with doing some work in CXF
>
>Thanks, Sergey
>>>