Modify Or/And to allow only one child, or else remove single-parameter QueryFactory methods. about cqengine HOT 5 CLOSED

Also should consider adding support for literal yes() and no() queries.

Original comment by [email protected] on 16 Jan 2014 at 4:03

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

from cqengine.

I'll keep this issue open as it's still under consideration (although I'm not 
sure how it could be implemented yet).

However just to add - the all() and none() queries can be used in a similar way 
as the yes() and no() queries proposed above.

Original comment by [email protected] on 20 Apr 2015 at 8:36

from cqengine.

Hi. I just ran into this while creating queries dynamically. (By parsing JSON-formatted MongoDB queries, by the way. It was surprisingly painless.) This restriction was easy to work around, but I thought I'd mention that the code is actually inconsistent with itself. There are versions of the and() and or() methods (for Java 6 compatibility) in the QueryFactory class that take a single Query argument. My vote would be to remove the restriction on the number of required subqueries, but otherwise I suppose that those single-argument methods ought to be removed.

from cqengine.

I've been thinking about this, and I agree. I will try to resolve this for the next release.

from cqengine.

I've decided to take the second option from earlier, which is to remove the QueryFactory methods which accept one parameter for and() or or() queries. These methods can safely be removed, because their previous behaviour was simply to throw an IllegalStateException.

Supporting single-parameter and() or or() queries would introduce too much complexity into the query engine, because and() and or() queries are evaluated recursively, unlike the child queries which they wrap. Supporting this might also introduce unnecessary complexity into indexes.

Applications which really do need single-parameter and() and or() queries, can easily work around this by defining their own single-parameter implementations of and() or or() as follows, and adding static imports wherever they are needed:

    public static <O> Query<O> and(Query<O> query) {
        return query;
    }

    public static <O> Query<O> or(Query<O> query) {
        return query;
    }

I did consider adding the workaround methods above into QueryFactory. However I'm pretty sure that if I did that, the next thing to occur would be people asking to allow zero-parameter and() and or() queries too.

There is a precedent for zero-parameter logical queries already: QueryFactory.in() does allows zero parameters. However a difference between in() queries, and and()/or() queries, is that it makes logical sense that a zero-parameter in() query should match no objects in the collection. Whereas it's not clear if a zero-parameter and() or or() query should match every object in the collection, or no objects in the collection. There is ambiguity there. Different people might expect different behaviour.

So to keep things simple (which in turn makes it easier to optimize performance internally too), I'd like to keep a general rule that and() and or() queries must have at least two child parameters. It's very easy for applications to work around these restrictions if they need to.

from cqengine.