Provide the feature of Query.CompositeFilter

[GoogleCodeExporter]

According to documentation, Query.addFilter() and Query.getFilterPredicates() 
are deprecated.

Query.CompositeFilter should be used, with Query.CompositeFilterOperator.AND.

Also, Query.setFilter() should be visible on the objectify query interface,
so one could use Query.CompositeFilterOperator.OR

Writing a wrapper around CompositeFilter, just to have one, is a bit pointless, 
and defining complex filters via the standard builder pattern would a bit 
confusing and ugly, because you don't have operator precedence and 
associativity, so a simple setFilter function on the objectify query interface 
seems to be the best solution.

use case: ((id=1 OR id=2343 or id=3) AND someproperty=3)

version: 4.0rc2

Original issue reported on code.google.com by simplex....@gmail.com on 18 Dec 2013 at 3:42

[GoogleCodeExporter]

Using Query.FilterOperator.IN is not an option, because of performance 
concerns, and it's limitations:
"The IN operator also performs multiple queries: one for each item in the 
specified list,
with all other filters unchanged and the IN filter replaced with an equality 
(=) filter.
The results are merged in order of the items in the list.
If a query has more than one IN filter, it is performed as multiple queries,
one for each possible combination of values in the IN lists.

A single query containing not-equal (!=) or IN operators is limited to no more 
than 30 subqueries."

Original comment by simplex....@gmail.com on 19 Dec 2013 at 11:01

[GoogleCodeExporter]

Objectify needs to support the capability of CompositeFilter. It probably won't 
be by exposing CompositeFilter directly because Objectify needs to be able to 
run translations on the values (eg Key<?> into native Key). But it should not 
be too hard to express the precedence rules with an easy-to-type syntax.

Original comment by lhori...@gmail.com on 23 Dec 2013 at 11:11

• Changed title: Provide the feature of Query.CompositeFilter
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

At least, it should replace the not-equal and IN operators internally, with 
Composite filters, to eliminate the subquery limitations.

It's also a good idea to collect filters addded with addFilter to a mandatory 
filters array, and also have an addOptionalFilter method for filters, also 
paired with an array, so we could set the filter once, internally, just before 
executing the query:

actual.setFilter(new CompositeFilter(CompositeFilterOperator.AND, Arrays.asList(
    new CompositeFilter(CompositeFilterOperator.AND, mandatoryFilters),
    new CompositeFilter(CompositeFilterOperator.OR, optionalFilters)
));

Original comment by simplex....@gmail.com on 24 Dec 2013 at 8:33

[GoogleCodeExporter]

Just curious if there is any progress on composite filter support. Even simple 
support for doing multi-property filtering would be much appreciated.

Original comment by edalqu...@google.com on 1 Apr 2014 at 4:34

[GoogleCodeExporter]

It's the next priority after rewriting the transmogrifier, which will probably 
be done by end of week. The biggest help would be to propose a 
programmer-friendly syntax for making this convenient. Best done on the Google 
group.

As a short-term fix, we could add a Query.filter(CompositeFilter) method that 
would accept the low-level api filter. It would be fairly dumb - it wouldn't 
understand Key<?> or any other translation, but it would provide the basic 
facility.

This is not a hard feature to add, it's just a hard API to design.

Original comment by lhori...@gmail.com on 1 Apr 2014 at 4:46

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I should note that 5.0 included the Query.filter(CompositeFilter) method, so 
you can perform composite queries today. They just aren't very convenient 
because they don't do automatic type conversion (ie, Key<?> to Key).

I will leave this issue open until Objectify has a "convenient" interface to 
composite queries.

Original comment by lhori...@gmail.com on 21 Apr 2014 at 3:57

[GoogleCodeExporter]

Status update?

Original comment by m...@marcmouallem.com on 8 Sep 2014 at 4:03

[GoogleCodeExporter]

The `Query.filter(CompositeFilter)` method is available now. If you want a more 
convenient interface, the best way to get forward progress on this is to 
suggest one on the google group :)

Original comment by lhori...@gmail.com on 8 Sep 2014 at 4:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The problems with the GAE composite filter. A) Objectify Translators are 
bypassed. B) Import collision with com.googlecode.objectify.cmd.Query mandates 
using fully qualified name C) Style clash between Google and Objectify syntax 
for filter operator. 

Maybe use the same interface style but have Objectify Filter and 
CompositeFilter Objects.
e.g. `Query.filter (CompositeFilter.or(Filter filterOne, Filter filterTwo)`

Or did you mean submit a patch :(

Original comment by m...@marcmouallem.com on 8 Sep 2014 at 4:43

[GoogleCodeExporter]

e.g. new Filter(String condition, Object value)

Original comment by m...@marcmouallem.com on 8 Sep 2014 at 4:45