Announcement Announcement Module
No announcement yet.
MongoDB Near Query Strange Behavior Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • MongoDB Near Query Strange Behavior

    I have a near query I perform using Spring Data's MongoDB NearQuery operation. Everything works fine for the most part. However, I have my code on several test machines and a production machine. The query works on some of the test machines, yet it does not return results for newly created objects on the production machine and on one of my test machines. When I drop the mongodb collection on the machines that do not work, then use the same code to insert a new document and recreate the collection, the query begins to work again. My question is; what can cause this type of behavior? Can adding new variables to a class cause mongodb near queries to stop performing? If there are documents added to a collection with different variables than what already exist can that cause problems? In production, I can not simply drop collections to fix this. Is there something I am missing about keeping data in mongodb collections consistent so that my spring mongodb code continues to work?

    The mongoTemplate code:

    Point point = new Point(locationAsDoubleArray[0],locationAsDoubleArray[1]);
        NearQuery query = NearQuery.near(point.getX(),point.getY()).spherical(true).maxDistance(maxDistance,Metrics.MILES).distanceMultiplier(Metrics.MILES).query(regularQuery);//maxDistance(new Distance(radius,Metrics.MILES));
        GeoResults<CalendarEvent> results = ((MongoOperations)mongoTemplate).geoNear(query, CalendarEvent.class);
    The document that should be returned in JSON format:
    { "_class" : "" , "_id" : { "$oid" : "5011c5cf51527fce6c4d2a00"} , "_keywords" : [ "test" , "search" , "function" , "test" , ""] , "address1" : "221 East 5th Street" , "address2" : "" , "allDay" : false , "categories" : [ 14] , "city" : "Saint Paul" , "clientId" : 109 , "clientProductId" : 962 , "color" : "#003666" , "createUser" : "peterson.dean" , "description" : "test" , "end" : "2012-07-26 14:00:00" , "endDate" : { "$date" : "2012-07-26T19:00:00.000Z"} , "externalLink" : "<a href='http://'>More Info</a>" , "geoLocation" : [ -93.0875195 , 44.9490055] , "latitude" : 0.0 , "location" : "221 East 5th Street  Saint Paul,MN 55101 " , "locationManuallyEntered" : false , "locationName" : "My Cubicle" , "longitude" : 0.0 , "moreInfoLink" : "<a href='http://localhost:8080/posts/list/'>More Info</a>" , "note" : "" , "privateEventIn" : "N" , "restFormattedAddress" : "221+East+5th+Street+Saint+Paul,+MN+55101" , "start" : "2012-07-26 04:00:00" , "startDate" : { "$date" : "2012-07-26T09:00:00.000Z"} , "state" : "MN" , "title" : "Test Search Function" , "topicId" : 3150 , "url" : "http://localhost:8080/posts/list/" , "zip" : "55101"}
    The code works differently depending on the machine it is being run. I have ensured my jar files, etc. are identical on each machine. The only thing that will make the query work once it begins to fail, is to drop the collection and start over. I am not sure when or what causes the query to stop working however. I do not think the code is the problem. There may be some administrative task I do not know about that will clean the data. I have used the repair command already without any luck.

  • #2
    I had some old entries that had the long/lat order reversed. That caused all my near queries to fail. It is odd that having a few long/lat values in reverse order would cause this. Still, that is the cause. When I fixed the order of the long/lats for the entries in reverse, the queries are working again. To find this out I had to build and use direct mongodb commands in java rather than use Spring's succinct approach. By viewing the command's return value while debugging, I could actually see the error message about having incorrect values for latitude. No such errors were returned using Spring's near query operation. Spring's inadequate error messaging made this bug very hard to track down.