Modify Or/And to allow only one child, or else remove single-parameter QueryFactory methods.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create an or()/and() with only one child query.

What is the expected output? What do you see instead?
The result should check the return of the single child query.
An IllegalStateException is thrown saying that the query cannot have fewer than 
2 child queries.


What version of the product are you using? On what operating system?
1.2.6

Please provide any additional information below.

Original issue reported on code.google.com by Lewis.He...@cobraflow.com on 16 Jan 2014 at 12:24

[GoogleCodeExporter]

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

Original comment by ni...@npgall.com on 16 Jan 2014 at 4:03

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

[GoogleCodeExporter]

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 ni...@npgall.com on 20 Apr 2015 at 8:36

[sambishop]

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.

[npgall]

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

[npgall]

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.