|
Hmmm, I don't know how 2.4 resolves this ambiguity, but I could see how it would be between the two options you suggested. One thing you could try is to drop the index for endLocation and see if the results are sorted in the same order as before. If they are, that would seem to indicate that the last $nearSphere predicate "wins", and if not it could be an arbitrary index choice. If you're really curious about the actual code I'd suggest you post on the mongodb-dev Google Group.
Anyway, thanks for letting us know that using $centerSphere addresses your needs tredman@fb.com, I'm going to resolve this ticket then.
|
|
That makes sense. I just confirmed that I can swap out the other $nearSphere clauses with $centerSphere and get the same results in 2.6.5.
The context here is that one of our customers has documents that have multiple geopoints called startLocation and endLocation, and is issuing queries for docs where startLocation is near some point and endLocation is near some other point.
How does 2.4.x resolve this ambiguity? In testing, it looks like the results are sorted by the last $nearSphere encountered - does it just drop the other $nearSphere clauses or does it just pick one to sort against?
|
|
tredman@fb.com, this was a bug in 2.4 that was fixed in 2.6 – you can see the code here. The issue is that $near implies a sort by distance, so with two predicates is not clear what the ordering should be.
Could you please elaborate on what you're trying to do? There may be a way to do it using $centerSphere. Also, could you send a sample document?
|