[SERVER-21024] remove maxDistance in geoNear response if result set is empty Created: 20/Oct/15  Updated: 28/Dec/23

Status: Backlog
Project: Core Server
Component/s: Geo
Affects Version/s: 3.2.0-rc0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Emily Stolfo Assignee: Backlog - Query Integration
Resolution: Unresolved Votes: 1
Labels: qi-geo
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Integration
Participants:

 Description   

On previous versions of the server, if the result set is empty from a geoNear command, avgDistance was NaN. The following is using 3.0.7:

{
	"results" : [ ],
	"stats" : {
		"nscanned" : 12,
		"objectsLoaded" : 4,
		"avgDistance" : NaN,
		"maxDistance" : 0,
		"time" : 0
	},
	"ok" : 1
}

On 3.2.0-rc0, avgDistance is missing:

{
	"waitedMS" : NumberLong(0),
	"results" : [ ],
	"stats" : {
		"nscanned" : 10,
		"objectsLoaded" : 4,
		"maxDistance" : 0,
		"time" : 1
	},
	"ok" : 1
}

It seems that this is a bug as maxDistance is included even though it's 0.



 Comments   
Comment by Oliver Gierke [ 20/Jan/16 ]

You might wanna make sure that your community understands that semantics then. Nobody is expecting breaking changes in a middle digit upgrade really. What do you use the major version number for then? How do you actually ship bug fixes?

Anyway, I guess we're just going to assume nothing for granted going forward. Still the documentation fails to document the change in behavior properly.

Comment by Eric Milkie [ 20/Jan/16 ]

The semantics still apply; you simply have the "dev/release" semantics incorrect. The even/odd versioning scheme applies to the middle digit of the three digits in a particular version (3.0.x is release, 3.1.x is dev, 3.2.x is release, 3.3.x is dev, et cetera.). "3.2.0" would be a major version release. An example of a non-major version would be "3.2.1", and we take special care to avoid backwards breaking changes in such releases.

Comment by Oliver Gierke [ 20/Jan/16 ]

Okay, I was still assuming the even/odd version (dev/release) semantics applied. if that's not the case, I am not sure what you mean with that then:

This ticket is only describing proposed work and does not exist in any version yet.

3.2 does not return avgDistance for geo near commands that don't return a result. 3.1 did. So the problem is out there. In released versions. Without documentation updates. If you're even just remotely following semantic versioning a change like that is a major bug, and removing even more fields in a non-major version (anything that's not 4.0) makes things even worse, because that — by definition — is not what you expect to happen when upgrading minor versions.

Comment by Eric Milkie [ 20/Jan/16 ]

Versions 3.2.0 and 3.2.1 are fully supported releases intended for production uses. I do not consider them "non-major versions".

My plan is to remove a field that is currently returning erroneous metadata for certain queries. For applications that assume that the field is always present, they will need to change before upgrading to the version where this proposed feature first appears.

Comment by Oliver Gierke [ 20/Jan/16 ]

Well, I don't think there is too much. 3.2.0 and .1 are out in the wild and people use them (probably because they're not aware of the semantics of version scheme you use). Even acknowledging that, removing fields is an API breaking change. If your plan is to remove yet another field for 3.3, it's just going to expose more existing clients to the problem.

Comment by Eric Milkie [ 20/Jan/16 ]

oliver.gierke I apologise for the misunderstanding. This ticket is only describing proposed work and does not exist in any version yet. I will change the title to better reflect the work here.

Comment by Oliver Gierke [ 20/Jan/16 ]

You're removing fields from JSON exposed — i.e. introduce a breaking change — in a non-major version? You're not even updating the documentation to reflect that? Seriously?

Comment by Eric Milkie [ 20/Oct/15 ]

This was changed as part of the fix for SERVER-20272. At the time, it made sense to remove the field. I think we should remove maxDistance as well.
Note that mongos returns avgDistance as "0" instead of "NaN" in this case, which is also problematic.

Generated at Thu Feb 08 03:56:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.