Покажи схему

вот схема

Не используй Array

String / Number / Boolean, а остальные забирай из mongoose.Types.Schema.Ну и тут нужный тип

По пробуй сначала Mixed, если поможет, то создай схему и подключи её к этой схеме и сделай, чтобы она была массивом

я нихрена не понимаю, можно ссылку на ресурс , где всё это есть?

А что тебе не понятно?

Замени chanceMassive: {type: Array} на chanceMassive: {type: mongoose.Types.Schema.Mixed}

Замени chanceMassive: {type: Array} на chanceMassive: {type: mongoose.Types.Schema.Mixed}

неа, та же ошибка остается

блять неужели невозможно изменить массив из объектов

Можно т.к. куда тебя посылал, у человека всё сработало

Можно т.к. куда тебя посылал, у человека всё сработало

и что мне сейчас делать?

может быть я неправильно вызываю функцию

попытался вызвать updateMany(), один чел написал что ему это помогло ,у меня же выбросило ошибку что это не функция

Лучше $in использовать, чем $or

Лучше $in использовать, чем $or

с апдейтом бы разобраться сначала...

документ находится так что, ор или ин проблема не в этом

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

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

https://www.mongodb.com/docs/manual/reference/operator/update/addToSet/

документ находится так что, ор или ин проблема не в этом

ебааа я походу решил

Лучше $in использовать, чем $or

вот так работает

Так тоже не работает

Так тоже не работает

Что именно?

Что именно?

возвращает пустой массив, несмотря на совпадения

возвращает пустой массив, несмотря на совпадения

Ты ничего не return

return obj.tags === producttag

возвращает пустой массив, несмотря на совпадения

ну и к тому же сравнивать массив с одним тегом такое себе

Ты ничего не return

Все было еще хуже — я не заловеркейсил все, поэтому и возвращался пустой массив. Огромное спасибо, бесценный опыт

ну и к тому же сравнивать массив с одним тегом такое себе

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

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

Всего товаров будет не более 500(точно)

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

если у вас tags массив, то каконйить tags.include(tag), а то очень странно выглядит

если у вас tags массив, то каконйить tags.include(tag), а то очень странно выглядит

Массив products, в нем уже есть объекты (товары)

А уже у них tags, строка

А уже у них tags, строка

это строка? хех тогда мой коммент нерелевантен

это строка? хех тогда мой коммент нерелевантен

Да, у них там лишь по одной категории возможно Спасибо за отклик

Есть проблема, что при таком описании схемы, я соответственно не могу нормально популейтить внутри нее различные филды. Тут вопрос, можно ли как-то описать её корректно, учитывая что у меня эта дата может иметь разные варианты? Условно она может быть {text: String} , но может быть и {count: Number}

Есть проблема, что при таком описании схемы, я соответственно не могу нормально популейтить внутри нее различные филды. Тут вопрос, можно ли как-то описать её корректно, учитывая что у меня эта дата может иметь разные варианты? Условно она может быть {text: String} , но может быть и {count: Number}

Правильно понимаю, что это SubSchema?

Правильно понимаю, что это SubSchema?

Похоже на Subdocument, да. Пошерстил нет, но не нашел какого-то аналога к возможностям ТС. Только рекоммендацию использовать Discriminator

Похоже на Subdocument, да. Пошерстил нет, но не нашел какого-то аналога к возможностям ТС. Только рекоммендацию использовать Discriminator

А чем вас Generic не устраивает?

А чем вас Generic не устраивает?

Вы о mixed? С ним тоже монга не понимает что популейтить, даже с strictPopulate: false

Вы о mixed? С ним тоже монга не понимает что популейтить, даже с strictPopulate: false

Нет

Node замените на Node<T> Record<sting, any> замените на Record<string, T>

Привет всем. У меня есть массив обьектов(музыка) и в каждом есть числовое значение duration. Так же у меня есть обьект(альбомов), который связывает между собой обьекты(музыки). Как можно вывести общее кол-во duration в обьекте(альбомов)? Я вывел кол-во музыки в альбоме через aggregate, но не понимаю как это сделать с duration:

$group и в нем используй $sum

$group и в нем используй $sum

Спасибо. Уже сделал

db.words.find().forEach(function(doc) { db.new_words.insert({ "icon": doc.icon, "english": { "word": doc.englishWord, "definition": doc.englishDefinition }, "russian": { "word": doc.russianWord, "definition": doc.russianDefinition }, "bangla": { "word": doc.banglaWord, "definition": doc.banglaDefinition }, "isReadFromNotification": false, "isReadFromView": false, "level": doc.level, "userId": doc.userId, "isActive": false, "isComplete": false, "createdAt": doc.createdAt, "updatedAt": doc.updatedAt, }) });

иногда russian defination missing someing bangla defination sometime english defination что та не так мой код?

Друзья, я юзаю Express на бэке, ejs на фронте, passport.js для oAuth и Mongoose для СУБД. Есть проблема с тем, что когда я обновляю данные о юзере ( через метод .save() ) то у меня passportJS выкидывает юзера из сессии, то есть слетает авторизация у него и тем самым при дальнейшем взаимодействии с фронтом, где требуется аутентификация юзера, то соответственно выпадает ошибка 201. Кто сталкивался с подобной проблемой или есть кейсы решения? Почему при обновлении каких-либо данных в объекте текущего юзера - слетает авторизация

Ejs ещё актуален в 2022 ?

Ejs ещё актуален в 2022 ?

еще как

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

ребят, подскажите пожалуйста, на сервере запущена mongo в контейнере докера, база данных почти не используется, там порядка 6 коллекций и около 50 записей, которые иногда удаляются и добавляются новые, за месяц волюм mongodb вырос на 80мб, из-за чего такое может происходить?

даже за сегодня заметил рост волюма с 520мб, до 520.2мб

Спасибо конечно за совет, но просьба была в помощи решения тех.задачи, а не последствий, которые и так понятны, уже было исправлено, пропуск был важной функции authenticate() из-за чего пасспорт.жс не мог индефицировать какую стратегию использовать при данном роуте

даже за сегодня заметил рост волюма с 520мб, до 520.2мб

Это могут быть логи

Всем привет. Как я понял из документации mongodb ограничивает размер одного документа 16ю мегабайтами. От чего у меня возник вопрос: на практике, это ведь очень большой документ с огромной вложенной структурой? Если я моделирую базу под чаты (с не очень активной перепиской), то большого смысла разбивать чаты и сообщения две разные коллекции нет? 16 мегабайт это поидее тысячи вложенных сообщений, если реализовать через вложенные документы. И количество документов в коллекциях не будет активно расти, что наверное тоже плюс. Или я в чем то ошибаюсь?

Всем привет. Как я понял из документации mongodb ограничивает размер одного документа 16ю мегабайтами. От чего у меня возник вопрос: на практике, это ведь очень большой документ с огромной вложенной структурой? Если я моделирую базу под чаты (с не очень активной перепиской), то большого смысла разбивать чаты и сообщения две разные коллекции нет? 16 мегабайт это поидее тысячи вложенных сообщений, если реализовать через вложенные документы. И количество документов в коллекциях не будет активно расти, что наверное тоже плюс. Или я в чем то ошибаюсь?

Есть ограничение ещё на вложенность

Есть ограничение ещё на вложенность

Какое ограничение?

Какое ограничение?

100 "вложености". Точнее, ее то можна превисыть, но будут проблемы с производительностью и тд

Всем привет. Как я понял из документации mongodb ограничивает размер одного документа 16ю мегабайтами. От чего у меня возник вопрос: на практике, это ведь очень большой документ с огромной вложенной структурой? Если я моделирую базу под чаты (с не очень активной перепиской), то большого смысла разбивать чаты и сообщения две разные коллекции нет? 16 мегабайт это поидее тысячи вложенных сообщений, если реализовать через вложенные документы. И количество документов в коллекциях не будет активно расти, что наверное тоже плюс. Или я в чем то ошибаюсь?

Не надо реализовывать через вложенные документы. Если проект вырастет, а потом потребуется статистика по сообщениям или ещё какая инфа из них - выкапывать ее будет очень больно и очень медленно. Сталкивался с точно таким решением в живую, это - идеальный пример как делать не надо.

Понял. Спасибо всем за пояснения. 🍻

Однако хотелось бы уточнить пару моментов.)

100 "вложености". Точнее, ее то можна превисыть, но будут проблемы с производительностью и тд

Речь же идёт не про количество вложенных документов, а про уровни вложености? Т.е не более 100 уровней в глубину может быть вложенность. Про это ограничение идёт речь?

Речь же идёт не про количество вложенных документов, а про уровни вложености? Т.е не более 100 уровней в глубину может быть вложенность. Про это ограничение идёт речь?

каждое свойство, массив и тд + все что в них считается как +1

a b c q : a1, a2 пример json = тут будете иметь 6 "вложености"

a b c q : a1, a2 пример json = тут будете иметь 6 "вложености"

Почему-то в доке речь идёт именно про вложенность, а не про свойства. Т.е когда в документе появляются вложенные объекты или массивы.

Каждый обьект.... еще раз прочтите

Каждый обьект.... еще раз прочтите

Я понял. Но не обычное поле. В вашем примере a, b, c это отдельные объекты?

Я понял. Но не обычное поле. В вашем примере a, b, c это отдельные объекты?

да

это все 1 модель, вдруг что

это все 1 модель, вдруг что

Понял. Спасибо за пояснения!

Не надо реализовывать через вложенные документы. Если проект вырастет, а потом потребуется статистика по сообщениям или ещё какая инфа из них - выкапывать ее будет очень больно и очень медленно. Сталкивался с точно таким решением в живую, это - идеальный пример как делать не надо.

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

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

Тем что мы избавляемся от проблем с добавление нового функционала, упрощаем аналитики, укладываемся в требования заложенные БД и делаем более удобную структуру

Господа светлые умы с миллионным IP, подскажите, пожалуйста, есть ли mongo/mongoose какой-нибудь один метод, который создаёт документ, если он не существует, но при этом не падает с ошибкой дублирующего уникального ключа и не совершает upsert

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

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

Вот факинг щит. Ладно, спасибо за помощь!

Это могут быть логи

Логи контейнера?

Логи контейнера?

Монги