search

Suryakanta97 / odata4j

Automatically exported from code.google.com/p/odata4j
0 stars 0 forks source link

Create a common class for expression interpretation #67

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
It's not clear now what class is intended to be used to interpret $filter 
expressions (with support of all expressions described in OData spec). 

For my case there will be not enough to use InMemory feed or any other feeds. 
Computation of feed items for my case is time-consuming. The idea I with to 
implement is to reduce the number of items with help of expression analyzer (my 
code). That I with to make odata4j to run actual filtering of the resulting 
items.

Original issue reported on code.google.com by Eugene.P...@gmail.com on 11 Sep 2011 at 10:37

GoogleCodeExporter commented 9 years ago 
Please clarify what you're asking for.

odata4j helps out with parsing the $filter string to an expression (this work 
is common to all producers) but evaluating the expression is producer-specific. 

For example the JPA implementation creates and issues a jpql query, the 
In-Memory implementation evaluates objects in memory, etc.

Original comment by john.spurlock on 11 Sep 2011 at 12:30

GoogleCodeExporter commented 9 years ago 
I wonder if Eugene is looking for expression evaluation outside of the context 
of the InMemoryProducer?  I was.  I am currently working on queryable metadata 
that required evaluating $filters but not against a PropertyModel.  To decouple 
I refactored InMemoryEvaluation slightly to allow one to provide an arbitrary 
VariableResolver to the evaluator.  I should be checking in in the next day or 
so.

Original comment by tony.ro...@gmail.com on 27 Sep 2011 at 3:44