конечно. но раз вы такое задаете рекомендую погуглить что такое вообще аггрегации монгодб

Я почитал документацию, но что-то оно работает не так как я думал. await Info.findOneAndUpdate(infoObj, infoObj, { upsert: true }); Оно всё равно создаёт новые, в любом случае. Данные те же самые в первом и втором параметре

может оно тру по умолчанию

Если так то совсем ничего не добавляет)

чет я недогоняю. вам нужно что бы при отсутствии обновляемого документа он НЕ создавался?

я бы count использовал. его можно на индекс завязать. а find будет документ выгружать

Мне нужно что бы если этот объект уже есть оно его НЕ трогало, а если нету то создало

а если это штатная ситуация? каждый раз хэндлить эксепшн?

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

У меня есть эндпоинт который принимает поток с клиента(большой csv) и через readline добавляет по одной строке в бд, но я так понимаю это не очень эффективно, можно как-то кусками в бд закидывать? Желательно без дубликатов

У меня есть эндпоинт который принимает поток с клиента(большой csv) и через readline добавляет по одной строке в бд, но я так понимаю это не очень эффективно, можно как-то кусками в бд закидывать? Желательно без дубликатов

А можно как то рейзить из пайплайна ошибку если ничего не нашлось, а дальше ещё есть действия?

как правильно попгуглить, нужно findOneAndUpdate({status: 'ok', counter < 5} вот типо поле counter проверить

И да, если у вас нет с этим проблемы - не делайте ничего. "я так понимаю, это не очень эффективно" - не проблема

А будет работать не по индексам а по всему объекту? Потому что уникальных полей нет, только их комбинация уникальна. Для меня это не было бы проблемой, но сказали сделать максимально эффективно, а у меня каждый объект проверяется на уникальность перед добавлением(countDocuments), поэтому выходит очень долго.

Тоесть записать все параметры в дополнительный парметр и получится уникальный?

Есть вопрос к сообществу по бест практис в пагинации. Мы реализовали fast-pagination по objectID (objectID > last_id + limit [https://scalegrid.io/blog/fast-paging-with-mongodb/]). Но не учли, что в кластере (replica set) на каждой ноде генериуется разные objectID, что не позволяет их фильтровать по последнему полученному objectID. Если рассматривать генерацию ID до вставки на клиенте, для сохранения последовательности, то там также несколько нод в балансировке. Подскажите, пожалуйста, какие есть варианты “правильной” fast-pagination на кластере? Быстрый поиск не дал ответов на этот вопрос...

эм, как так на каждой реплике разные objectID?

Отличается все три части objectid, в зависимости от того на какую ноду пришел запрос на создание. Вне зависимости от кластеризации _id должен расти последовательно? Я имею ввиду должна меняться только последняя часть _id. Мы не задаём Id при создании на клиенте. Но ваш вопрос навёл меня на мысль, что может быть библиотека генерит сама его до вставки и в зависимости от ноды она выдает разный результат.

Ну или просто к записям добавить поле created: IsoDate(), индекс по нему и сортировать\ограничивать по этому полю, а не ObjectID, если все же окажется, что ObjectID не подходит по какой либо причине

Спасибо. Индекс дополнительный не хотелось навешивать, так как запросов на вставку на порядки больше чтения. Но посмотрю либу, наверное она генерит в зависимости тот ноды

А, в этом смысле, я просто подумал, что у Вас репликасет и каждая из реплик отдает для одной и той же записи разные ObjectID и решил, что я явно что-то упустил в этой жизни. Но вообще: https://docs.mongodb.com/manual/reference/method/ObjectId/ Если верить доке монги, то ObjectID (если он генерируется правильно, а не от фонаря), должен возрастать со временем. Т.е. по нему можно спокойно сортировать вне зависимости от того, на какой из нод он был сгенерирован (если считать, что везде часы правильные)

День добрый, странный вопрос, может кто сталкивался. Суть в том, что мне надо добавить для записей новое автоинкрементируемое поле что-то item_num : 1 Которое будет int от 1 до бесконечности И чтобы оно всегда увеличивалось для новых записей И если была запись с макс item_num : 55 ее удалили, чтобы следующая при создании атоматически получила item_num : 56 и были бы записи с item_num : 54 и 56 как-то так Подскажите пожалуйста варианты для решения такой задачи?

коллекция для инкрементов.

А можно более подробнее?

ну создаешь коллекцию для инкрементов)) при добавлении в нужную коллекцию, миддлварой model.pre('save') берешь инкремент и присваиваешь его для item_num и инкрементируешь инкремент (тавтология)

идею понял, но это же просто жесть :) мол чисто инкремент зранить в отдельной колекйции и все время ее дергать, а когда дернул +1

День добрый, странный вопрос, может кто сталкивался. Суть в том, что мне надо добавить для записей новое автоинкрементируемое поле что-то item_num : 1 Которое будет int от 1 до бесконечности И чтобы оно всегда увеличивалось для новых записей И если была запись с макс item_num : 55 ее удалили, чтобы следующая при создании атоматически получила item_num : 56 и были бы записи с item_num : 54 и 56 как-то так Подскажите пожалуйста варианты для решения такой задачи?

Пересмотреть причину зачем это надо

ну если жесть то тогда postgre mysql бери

Спросите сколько ресурсов он готов на это потратить

Ага, только перешли с mysql На монгу :)

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

Это больше чем сутки работы

я вообще топлю против этой идеи И топлю, что _id и так огонь Но он типо некрасивый и неудобно называть а ссылку скинуть сложно тип чтобы можно было сказать посмотри запись 566

Используйте _id, но преобразуйте его в человекочмтаемый вид «дата-счётчик-хост»