Consider merging duplicate key criteria with $and instead of throwing an exception in Query#addCriteria

[anjeongkyun]

When building queries dynamically, it's fairly common to end up calling addCriteria() multiple times with criteria that share the same key — for example, applying both a lower and upper bound on the same field via separate code paths.

Currently, addCriteria() throws an InvalidMongoDbApiUsageException in this case:

query.addCriteria(where("amount").gte(100));
query.addCriteria(where("amount").lte(500)); // throws

The workaround is to collect all criteria into a list and wrap them with andOperator(), which works fine but isn't obvious and forces callers to restructure their query-building logic just to avoid the exception.

It would be nice if addCriteria() (or a new variant) could automatically merge conflicting criteria under a $and instead of throwing. MongoDB handles this just fine:

{ "$and": [ { "amount": { "$gte": 100 } }, { "amount": { "$lte": 500 } } ] }

I understand there might be concerns around changing existing behavior, so a separate method like addCriteriaOrAnd() or a flag on Query could be an option.

[christophstrobl]

related issue: #4715

[xxxxxxjun]

While looking into this I hit a related case that doesn't throw at all.

Query#addCriteria keys off CriteriaDefinition#getKey(), which for a chained Criteria is only the last key in the chain. When the duplicate key sits earlier in the chain the check doesn't fire, and one of the two conditions is dropped while the query document is built:

Query query = new Query();
query.addCriteria(where("amount").gte(100).and("status").is("NEW"));
query.addCriteria(where("amount").lte(500));

query.getQueryObject(); // { "amount" : { "$lte" : 500 }, "status" : "NEW" }

The $gte bound is gone, so the query matches more documents than intended and nothing reports it. Plain equality behaves the same way:

query.addCriteria(where("amount").is(100).and("status").is("NEW"));
query.addCriteria(where("amount").is(200));

query.getQueryObject(); // { "amount" : 200, "status" : "NEW" }

Verified on main (5.2.0-SNAPSHOT).

I'd be glad to work on this, but I'd rather not guess the direction, especially since #4715 states the implicit $and form isn't supported in the Criteria API on purpose. Would any of these be acceptable?

• Keep the current behavior and only close the gap above, so a duplicate key inside a chain is rejected instead of dropping a condition.
• Merge duplicates into $and, either as the default or behind an explicit opt-in.
• Leave addCriteria as is and look at the query derivation side mentioned in Support derived queries using the same field multiple times #4715.

Happy to open a PR once the direction is settled.

[anjeongkyun]

@xxxxxxjun thanks for digging into this, I confirmed both cases you posted still reproduce on main.

I have opened #5250 for the silent condition loss only, which is your first option and the part that needs no decision: Criteria already refuses that duplicate inside a single chain, so the two paths just disagree today. Your name is on the commit.

The $and merge this issue actually asks for is untouched and still yours if you want it. Sorry for stepping in on the narrow half, five weeks with no direction seemed long enough for the part that does not need one.