натолкнулся вот на такой баг : https://jira.mongodb.org/browse/SERVER-14322

как правильно разрешать на клиенте ситуацию? Ловить duplicate key exception ? Или есть элегантнее способы? Спасибо

И напоследок такой вопрос: PostSchema .virtual('comments') .get(function () { // Нормально будет, если здесь возвращать массив комментариев? // Выполнять populate по коллекции Comments? return [] })

Че то я дичь спросил ))) Как я собрался возвращать, если запрос асинхронный ))

В коллекции Comments лежат комментарии, но комментарии могут относиться не только к Answer, но и к Post. Как мне указать ref? target: { type: Schema.Types.ObjectId, ref: 'Answer' // но может быть и Post },

как правильно разрешать на клиенте ситуацию? Ловить duplicate key exception ? Или есть элегантнее способы? Спасибо

Ожидать и обрабатывать ошибку в соответствии с бизнес логикой, да.

Понятно, спасибо, ну я так и делаю Думал может есть какой то элегантный способ.

Не использовать upsert ;)

нуууу это понятно) но я lazy

а есть какие-то бест практис почитать на тему проектирования под документарные СУБД на подобие монги?

https://derickrethans.nl/mongo-date-time.html @rarwin тебе понравится :D

а есть какие-то бест практис почитать на тему проектирования под документарные СУБД на подобие монги?

https://www.mongodb.com/blog/post/thinking-documents-part-1

и дальше по крупицам собирать подобные статьи

https://derickrethans.nl/mongo-date-time.html @rarwin тебе понравится :D

Это в новой версии будет?

вообще всё сводится к более простой проблеме — для реляционных и нереляционных данных не все паттерны эффективно работают

Это в новой версии будет?

угу, в 3.6

Выглядит удобно, хотя и не всё применимо в моём случае. Но $hour и похожие - очень полезно, не придётся сдвигать руками.

questionSchema .virtual('slug') .get(function () { return translit(this.title || '') }) Как сделать, чтобы virtual поля не высчитывались, если их не запрашивают явно? Например я делаю запрос к коллекции, где у меня { select: { author: 1 } } и мне поле slug не нужно. Но оно все равно есть в результате.

Решил самописным фильтром

Добрый день, это нормальная практика, если _id это строка? Хочу сделать составной ключ типа "tenantId:userId"

Оно будет использоваться только для поиска, поиск по отдельным полям мне не нужен

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

остается только вопрос в том насколько это нормальная практика и есть ли другие способы решения

нормальная практика. + Экономия на одном индексе)

Если ключ меньше 1кб, то да.

Правда если поиск будет не по прямому совпадению или не по префиксу, то без индекса по userId может быть туго.

Добрый день, это нормальная практика, если _id это строка? Хочу сделать составной ключ типа "tenantId:userId"

постоянно юзаю, в reseach очень помогает мнемонически понятные ключи

спасибо за ответы

я правильно понимаю, что в монге нет отдельных типов для byte и short, и что если мне нужно хранить только диапазон значений от 0 до 10, то всеравно это будет инт и жрать будет все 4 байта?

или он сумеет сжать его до 1 байта дляя более компактного хранения

Чатом ошиблась что ли

угу, подкачать надо немного

или он сумеет сжать его до 1 байта дляя более компактного хранения

Не в монге, а в bson. Нет, нету. Можешь посмотреть сколько в строке займёт, если в один символ ужать.

http://bsonspec.org/spec.html

строка эт конечно инетресный вариант))) чет про такое даж не думал

Но кажется будет 3 байта

Да, три string ::= int32 (byte*) "\x00"

но строки мне не очень подойдут, мне нужен индекс с услвоием, чтобы большую часть доков не индексировать

Забей и в интах храни тогда

да уже)

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

Смысла мало

Вы тут живые?

По какой-то причине нативный драйвер mongodb для node.,js не хочет отдавать нормальный промис и отдает, как я понимаю, курсор

Если тыкать .toArray() или .next() на курсор, то он тупо возвращает все/первое значение

Оберни с помощью util.promisify

Оберни с помощью util.promisify

блэт, серьезно?

А, там апи с промисами есть, сорри)

Здравствуйте, подскажите такую вещь. Есть документ типа: { _id: 'ObjectId', creator: 'ObjectId("ID пользователя")', //куча нужных полей comments: [ { user: ObjectId("ID пользователя"), comment: String }, { user: ObjectId("ID пользователя"), comment: String }, { user: ObjectId("ID пользователя"), comment: String } ] }

нужно подставить в creator {id, name} пользователя и в каждый эл. массива то же в user

я смог придумать только aggregate { $lookup: { "from": "users", "localField": "creator", "foreignField": "_id", "as": "creator" } }, {$unwind: '$creator'}, {$unwind: {"path": "$comments", "preserveNullAndEmptyArrays": true}}, { $lookup: { "from": "users", "localField": "comments.user", "foreignField": "_id", "as": "comments.user" } }, { $unwind: {path: '$comments.user', "preserveNullAndEmptyArrays": true} }, {$group: сгруппировать в исходное} затем пробежать по массиву comments и убрать у user ненужные поля

ну пожалуйста..

а сразу имена в комменте сохранять не?

чтоб потом за ними не лазить

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

up

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

это тебе не sql

Так дело в том, что я не знаком с sql . Тут стоит mongo , что есть то есть..

я правильно понял, что Mongo не предусматривает большую вложенность обьектов ?

https://docs.mongodb.com/manual/reference/limits/#Nested-Depth-for-BSON-Documents

MongoDB supports no more than 100 levels of nesting for BSON documents.

ну и лимит в 16Мб на документ

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

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

Если тайм-аут не выставлен, то вечно

@dd_bb а это нормально иметь 5к чанков при шардирвоании? и есть ли рекомендации по количеству чанков на ноду?

А почему ненормально?

ну мало ли) просто переделали в шарды начали заливать данные и хз как расценивать много это или мало, мол надо чтото предпринимать или нет

по 2.5к на ноду пока

Ну нормально.

нет никаких высоких значений, чтобы начинать что-то предпринимать, например 50к чанков на ноде или 100к

?

Цифры мало на что влияют. Единственное неудобство — миграции по сути ограничена одним чанком на ребро графа в единицу времени

Графа связи между шардами в смысле

это уже ощутил, пришлось делать пресплит с ручной миграцией пустых чанков

А так, когда будет тормозить, тогда и надо думать

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

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

сейчас выставили в максимум 1024, т.к. данных достаточно много, как мне кажется. Кроме как очень долгой миграции одного чанка есть какието пробелмы с этим?

Подскажите хорошие онлайн курсы, где сертификат получить можно по сабжу?

https://university.mongodb.com

сейчас выставили в максимум 1024, т.к. данных достаточно много, как мне кажется. Кроме как очень долгой миграции одного чанка есть какието пробелмы с этим?

Есть конечно.

Чанки будут разрежённые

Хотя.

Да, всё правильно. У тебя буду чанки неравномерно заполнены, что скорее всего приведёт к перекосам в количестве данных после балансировки.

Но это зависит в первую очередь от документов. Если у них большой разброс в размерах — может быть очень печально.

Ну и миграции будут долгие.

ну значит ничего страшного, полупустые это нормально, с перекосами думаю балансер сам справится если вдруг прям оч сильно будет