На этот вопрос только вы сами можете ответить. Смотрите логи, берите в руки отладочные инструменты

У меня есть подозрение что в бесплатной версии Атлас специально «мозги е;;т»

почему если в моей программе я 10 раз выполняю авторизацию и выход из приложения все может летать - а на 11 раз весит 30 секунд в статусе ожидания? При чем я сам свой ‘server.js’. вообще не трогаю

Это не группа про JS. Как я вам выше написал, только вы можете найти причину. Возьмите в руки отладочные инструменты и ищите где конкретно у вас проблемы. Как минимум посмотрите на логи запросов в монгу

Это не группа про JS. Как я вам выше написал, только вы можете найти причину. Возьмите в руки отладочные инструменты и ищите где конкретно у вас проблемы. Как минимум посмотрите на логи запросов в монгу

почему если в моей программе я 10 раз выполняю авторизацию и выход из приложения все может летать - а на 11 раз весит 30 секунд в статусе ожидания? При чем я сам свой ‘server.js’. вообще не трогаю

Потому что limit запросов к API чего-то там у вас может быть, идите в @nodejs

ребзи, а подскажите как быть с айдишниками монги в пхп при передаче на фронт их преобразуют в строку, а в бд они лежат в таком виде: ObjectId("5d8b754cb3829ada94a05902") найти в бд по строковому id, а там ObjectId, и наоборот, ищу по ObjectId. а там случайно строковые id с фронта сохранились как правильно это организовать? нельзя в бд просто хранить строковые id и не мучаться?

чем ObjectId лучше строки вообще?

Как лучше организовать проверку на валидность DBRef при сохранении модели? Что _id был релеватным.

Привет всем. Если у меня есть документы вида: { _id: 123, name: "sample", events: [ {state: "attached"}, {state: "processed"}, {state: "broken"} ] } И я выполняю поиск: { "events.state": "broken" } То есть ли возможность понять какой по счёту event совпал при поиске документа?

Привет всем. Если у меня есть документы вида: { _id: 123, name: "sample", events: [ {state: "attached"}, {state: "processed"}, {state: "broken"} ] } И я выполняю поиск: { "events.state": "broken" } То есть ли возможность понять какой по счёту event совпал при поиске документа?

Тебе нужно уточнять по какому-либо параметру из какого документа тебе доставать.

Вот тут не понял. Чем именно я могу так сделать?

Привет всем. Если у меня есть документы вида: { _id: 123, name: "sample", events: [ {state: "attached"}, {state: "processed"}, {state: "broken"} ] } И я выполняю поиск: { "events.state": "broken" } То есть ли возможность понять какой по счёту event совпал при поиске документа?

Окей, тут короче фокус в том, что я сильно-сильно упростил задачу. На самом деле в events лежит монстр в котором 40 ключей. Под этого монстра пишутся запросы вида events.monster_value: {$in: [a, b]}, lte, gte, in, nin, neq, eq и всё остальное. Мне нужно, по хорошему, оставить в массиве events только те элементы, которые были причиной, почему документ попал в результаты

Здравствуйте. Хотелось бы узнать, возможна ли реализация в монге или в мангусе capped-массивов? То есть ограниченнных массивов, работающих по принципу очереди: при превышении лимита размера массива, при добавлении нового элемента первый элемент в массиве удаляется. Пока что смог найти лишь метод validate для мангуса, но в данном случае он может только выкидывать ошибку. Можно конечно это сделать, запихнув в update метод aggregation pipeline, и ручками добавить элемент, проверить размер и удалить старый, если лимит превышен. но какое-то это неэлегантное решение, и мне кажется, это тяжелая с точки зрения производительности функция, так что если есть какие-нибудь нативные решения или лайвхаки, я бы их лучше использовал.

вопрос решился быстро, просто еще раз заглянул в документацию и нашел метод $slice))

Коллеги, а как будет по-русски multikey indexes ?

Я не знаю как в 2.6, но в 3.4+ я удалял репликасет и инитил его снова, потому что изменить параметры репликасета не являясь мастером нельзя с помощью rs.conf

Т.е. из конфига убрать строчку, которая задает replicaset?

Закомменти просто ага

всем 👋 возможно, сейчас спрошу что-то нубское, но всё же: допустим, мне нужны транзакции (и, насколько я понимаю, таким образом replica-set), но я не хочу заниматься администрированием распределённой системы, да и, в принципе, некоторое время даунтайма меня устраивает, если что-то там упадёт. могу ли я (учитывая эти условия) запускать в продакшене replica-set из одного инстанса и будет ли это концептуально то же самое, что и запуск standalone версии монги? например, так (с последующим `rs.initiate()`): docker run mongo:latest mongod --replSet rs0

После запуска необходимо инициализировать реплика-сет https://docs.mongodb.com/manual/tutorial/deploy-replica-set/

localhost по-моему у вас не получится использовать

получилось, rs0:PRIMARY> rs.conf() { "_id" : "rs0", ... "members" : [ { "_id" : 0, "host" : "localhost:27017", ... } ], ... }

а работает?

Ребят, всем пример. Подскажите, Я вообще могу делать Object of Object в монго. К примеру: { _id: 'abc', descr: '...', myObjects: { type: Object }, } А потом что то вроде $push => abc.myObjects[ 'myKey_A' ] = {} abc.myObjects[ 'myKey_B' ] = {}

Я попробовал, и оно работает. Теперь такой вопрос, хранить Object of Object, будет ли это быстрее с точки зрения поиска ? тоесть вот так { <unieque-key>: { ... }, <unieque-key>: { ... }, } ли вот так будет быстрее [ {<unieque-key>: { ... }}, {<unieque-key>: { ... }}, ]

я про это и говорю что первый вариант будет быстрее. так как он имеет вот такой вид { <unique-key>: {}, <unique-key>: {}, } В второй [ {<unique-key>: {}}, {<unique-key>: {}}, ]

не будет он быстрее

тогда вы сможете сделать индекс и по _id и по value

Добрый вечер,не подскажите какой оператор выборки необходимо использовать,что бы вывод осуществлялся только если подтверждается одно из двух условий?