Коллекция запросов Spring mongo для свойства с символом подчеркивания

Я создаю запрос для извлечения элементов из коллекции монго, используя MongoTemplate. Критерии запроса содержат свойство со знаком подчеркивания, которое каким-то образом заменяется на '._', в результате чего запрос всегда возвращает 0 элементов.

Criteria matchingCriteria = Criteria
.where("entries").elemMatch(Criteria.where("app_id").is(appId))

Глядя на журналы, я вижу сгенерированный запрос следующим образом:

o.s.data.mongodb.core.MongoTemplate: find using query: { "entries" : { "$elemMatch" : { "app._id" : "5834718ab0"}}} fields: null for class: Ranking in collection: ranking

Я уже пытался использовать BasicQuery, подчеркивая символ «\\» и используя юникод «app_id». Ни один из них не работал. Важно отметить, что в моей базе данных существует коллекция с именем «app».

Поведение не выглядит стандартным. Когда я использую другое свойство с подчеркиванием, значение не заменяется:

Criteria matchingCriteria = Criteria .where("entries").elemMatch(Criteria.where("unique_app_id").‌​is(appId))

Журналы:

o.s.data.mongodb.core.MongoTemplate find using query: { "entries" : { "$elemMatch" : { "unique_app_id" : "1131706359"}}} fields: null for class: class Ranking in collection: ranking

записи представляют собой массив с коллекцией в следующем формате:

{
    "instanceId" : "654ba2d16579e",
    "app_id" : "583471adb0",
    "unique_app_id" : "554577506",
    "value" : 169
 }

Стоит отметить, что тот же запрос (без замены символа подчеркивания) отлично работает в IDE mongo (в данном случае Robomongo).

Я использую spring-boot-starter-data-mongodb 1.4.1.RELEASE.

У меня сейчас совсем нет идей.

Любое предложение ?


java spring mongodb mongotemplate underscore.js
person guanabara    schedule 16.02.2017    source источник
comment
Возможный дубликат репозитория Spring-Data-Jpa - подчеркивание в столбце сущности Имя   -  person Keith    schedule 16.02.2017
comment
Можете ли вы добавить пример entries документа к своему вопросу?   -  person Keith    schedule 16.02.2017
comment
Добавлено к исходному вопросу @Keith.   -  person guanabara    schedule 16.02.2017

Ответы (1)


arrow_upward
3
arrow_downward

Согласно разделу 3.4.3 этого документация Spring Data Commons:

Поскольку мы рассматриваем символ подчеркивания как зарезервированный символ, мы настоятельно рекомендуем следовать стандартным соглашениям об именах Java (т. е. не использовать символы подчеркивания в именах свойств, а вместо этого использовать верблюжий регистр).

Я не верю, что вы можете использовать символ подчеркивания в середине имени элемента, используя Spring. Ручные ссылки называются в честь коллекции, на которую ссылаются. Используйте тип документа (название коллекции в единственном числе), за которым следует _id ( <document>_id ). Это единственный случай, когда вы можете использовать подчеркивание в середине.

Обновление: вот существующий запрос на вытягивание для точного поведения, которое вы видите, а также отслеживание ошибок Spring для этого.

Из оболочки Mongo я могу успешно выполнить следующий запрос:

> db.app.findOne({ "entries" : { "$elemMatch" : { "app_id" : "1"}}})
{
    "_id" : ObjectId("58a5bc6afa8dd4ae3097d5f7"),
    "name" : "Keith",
    "entries" : [
        {
            "instanceId" : "654ba2d16579e",
            "app_id" : "1"
        }
    ]
}

Итак, возможно, Spring API не разделяется, когда находит несколько токенов _ при анализе критерия, но делает разделение для обхода при анализе одного.

person Keith    schedule 16.02.2017
comment
Добавил некоторые детали в исходный вопрос. - person guanabara; 16.02.2017
comment
Интересный. Что произойдет, если вы запустите запрос из оболочки mongo? - person Keith; 16.02.2017
comment
Проверьте мое последнее обновление к моему ответу. Мне было бы интересно посмотреть, как Spring отреагирует, если вы обновите документ с app_id до app__id (два символа подчеркивания) и обновите свой запрос с помощью .elemMatch(Criteria.where("app__id"). Трудно сбрасывать со счетов известную ошибку, на которую я ссылался, — я сильно подозреваю, что она виновата. - person Keith; 16.02.2017