dongyanfeng0546 2017-07-25 23:08
浏览 168
已采纳

mongoDB $ sort结果不一致

I have the following query in go lang which works fine:

query["name"] = bson.M{"$regex": searchStr, "$options": "i"}
query["likes"] = userSession.Id
c.Find(query).Skip(0).Limit(2).Select(bson.M{"name":1, "profile":1, "description":1, "user_id":1, "likes":1}).Sort("-pro", "-check").All(&business);

Then I tried to write the same query using the aggregation framework:

query["name"] = bson.M{"$regex": searchStr, "$options": "i"}
query["likes"] = userSession.Id
oe := bson.M{
    "$match" :query,
}
oa := bson.M{
    "$project": bson.M {"pro": 1, "check": 1, "name":1, "profile":1, "description":1, "user_id":1, "likes":1, "nrLikes": bson.M{ "$size": "$likes" }, "city": 1, "country": 1, "industry": 1},
}
ol := bson.M{
    "$limit" :pageSize,
}
os := bson.M{
    "$skip" :skips,
}
or := bson.M{
    "$sort" : bson.M {"pro": -1, "check": -1},
}

pipe := c.Pipe([]bson.M{oe, oa, or, os, ol  })

pipe.All(&business)

The second query works fine 90% of the time, but 10% of the times it returns a different order for results.

Any thoughts?

Later edit: Here are the resuls

[]bson.M{
{
    "description": "<p>sasdfdasf</p>",
    "profile":     []interface {}{
        "rKwMmXPWheGczwvGn2TzSRU7jRorhorKwMmXPWheGczwvGn2TzSRU7jRorho=0.jpg",
    },
    "likes": []interface {}{
        "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    },
    "nrLikes":  int(1),
    "name":     "ediloc.com2",
    "city":     "Calimanesti",
    "industry": "Automotive",
    "_id":      "Yo\xd4f\x1a\xa9Q|w\tG^",
    "user_id":  "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    "country":  "Romania",
},
{
    "_id":         "Yo\xc7\xd7\x1a\xa9Qy1['\xea",
    "user_id":     "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    "name":        "ediloc.com",
    "country":     "Romania",
    "description": "<p>a</p>",
    "profile":     []interface {}{
        "1ssSySNRZwGJJwqzXghL6qzAVfWZis1ssSySNRZwGJJwqzXghL6qzAVfWZis=1.jpg",
    },
    "likes": []interface {}{
        "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    },
    "nrLikes":  int(1),
    "city":     "Calimanesti",
    "industry": "Accounting",
},
}


[]bson.M{
{
    "likes": []interface {}{
        "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    },
    "_id":     "Yo\xd4f\x1a\xa9Q|w\tG^",
    "name":    "ediloc.com2",
    "city":    "Calimanesti",
    "country": "Romania",
    "profile": []interface {}{
        "rKwMmXPWheGczwvGn2TzSRU7jRorhorKwMmXPWheGczwvGn2TzSRU7jRorho=0.jpg",
    },
    "user_id":     "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    "industry":    "Automotive",,
    "nrLikes":     int(1),
},
{
    "_id":      "Yo\xc7\xd7\x1a\xa9Qy1['\xea",
    "user_id":  "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    "industry": "Accounting",
    "profile":  []interface {}{
        "1ssSySNRZwGJJwqzXghL6qzAVfWZis1ssSySNRZwGJJwqzXghL6qzAVfWZis=1.jpg",
    },
    "likes": []interface {}{
        "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    },
    "nrLikes":     int(1),
    "name":        "ediloc.com",
    "city":        "Calimanesti",
    "country":     "Romania",
    "description": "<p>a</p>",
},
}


[]bson.M{
{
    "nrLikes":     int(1),
    "user_id":     "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    "description": "<p>a</p>",
    "profile":     []interface {}{
        "1ssSySNRZwGJJwqzXghL6qzAVfWZis1ssSySNRZwGJJwqzXghL6qzAVfWZis=1.jpg",
    },
    "country":  "Romania",
    "industry": "Accounting",
    "likes":    []interface {}{
        "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    },
    "_id":  "Yo\xc7\xd7\x1a\xa9Qy1['\xea",
    "name": "ediloc.com",
    "city": "Calimanesti",
},
{
    "name":        "ediloc.com2",
    "industry":    "Automotive",
    "description": "<p>sasdfdasf</p>",
    "likes":       []interface {}{
        "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    },
    "user_id": "Yo\xc7;\x1a\xa9Qy\b\xb8\xa2\xf9",
    "city":    "Calimanesti",
    "country": "Romania",
    "profile": []interface {}{
        "rKwMmXPWheGczwvGn2TzSRU7jRorhorKwMmXPWheGczwvGn2TzSRU7jRorho=0.jpg",
    },
    "nrLikes": int(1),
    "_id":     "Yo\xd4f\x1a\xa9Q|w\tG^",
},
}

Pro and check fields are in32, the documents with higher pro field number should have priority over the documents that have higher check fields.

  • 写回答

1条回答 默认 最新

  • dsoy71058 2017-07-26 10:29
    关注

    Make sure you have your sort pipeline stage before your limit & skip stages. You can only reliably obtain the same results with limit/skip on sorted input.

    EDIT

    Realised that you are using bson.M {"pro": -1, "check": -1} to define your sort order. The iteration order of a map is unspecified in Go and can change. Hence this is probably why you are getting inconsistent results.

    Try changing this to a bson.D so that the order of columns to sort by is maintained.

    It make help to see how the query Sort method constructs this from the strings you provide.

    For your use case, you would change the or variable to:

    or := bson.M{
        "$sort": bson.D{
            bson.DocElem{Name: "pro", Value: -1},
            bson.DocElem{Name: "check", Value: -1},
         },
    }
    
    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 完成下列问题完成下列问题
  • ¥15 C#算法问题, 不知道怎么处理这个数据的转换
  • ¥15 YoloV5 第三方库的版本对照问题
  • ¥15 请完成下列相关问题!
  • ¥15 drone 推送镜像时候 purge: true 推送完毕后没有删除对应的镜像,手动拷贝到服务器执行结果正确在样才能让指令自动执行成功删除对应镜像,如何解决?
  • ¥15 求daily translation(DT)偏差订正方法的代码
  • ¥15 js调用html页面需要隐藏某个按钮
  • ¥15 ads仿真结果在圆图上是怎么读数的
  • ¥20 Cotex M3的调试和程序执行方式是什么样的?
  • ¥20 java项目连接sqlserver时报ssl相关错误