Из шелла - записи в массиве нет

значит ничего не сохраняется

проверяйте схему в монгусе

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

потому что монгус

И updatedAt обновляется - видно в т.ч. по шеллу

если обновляется время значит схема описана криво и массив не сохраняется

точнее элементы не сохраняются

как у вас задана схема7

Логал все, очень странная ситуация, схеме соответсвует, видимо дело в предшествующем коде, потому что updatedAt в следующем запросе - секундой позже, чем пришло из кода

Логал все, очень странная ситуация, схеме соответсвует, видимо дело в предшествующем коде, потому что updatedAt в следующем запросе - секундой позже, чем пришло из кода

монгус без схемы?

И да, в одной ситуации сохраняет норм, в другой нет, в зависимости от кода до, даже если пушить в массив захардкоженное значение Видимо точно дело не в монгусе

монгус без схемы?

Со схемой

audio: { type: [{ _id: false, s3Path: String, duration: Number }], default: [] },

не так прочитал

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

или монгус запускает

Баг был на фронте, спасибо :^)

Кто нибудь участвовал в обучении от Монго ? Как бы вы решили эту задачу? Необходимо вернуть "title" и "_id" фильма. Странная обучалка у них. Что бы её запустить, с Node пришлось сутки мучиться из-за их бага.

Кто нибудь участвовал в обучении от Монго ? Как бы вы решили эту задачу? Необходимо вернуть "title" и "_id" фильма. Странная обучалка у них. Что бы её запустить, с Node пришлось сутки мучиться из-за их бага.

У них на форуме для каждого курса есть обсуждение. Если ошибки, то там уже есть описание, что делать. На форуме и про как решить тоже есть подсказки. В самом задании написано что нужно сделать и как.

ребят подскажите плиз как сделать запрос к монге из баша

ну типа mongo —shell show dbs

задча в том что бы при создании контейнереа он делал бд и создавал индексы

задча в том что бы при создании контейнереа он делал бд и создавал индексы

сделайте контейнер сразу с пустой базой и индексами

а можно пример ?

пример чего? docker commit?

задча в том что бы при создании контейнереа он делал бд и создавал индексы

это какой-то pet-project?

ну типа mongo —shell show dbs

https://docs.mongodb.com/manual/tutorial/write-scripts-for-the-mongo-shell/#scripting

нет есть композ в котором есть монга, для разрабов. Просто приходится ходить ручками в контейнер и делать бд и коллекции

нет есть композ в котором есть монга, для разрабов. Просто приходится ходить ручками в контейнер и делать бд и коллекции

идея делать это в контейнере _очень_ опасная

вы ищите «миграции», вероятно ваш ODM в них умеет

нет есть композ в котором есть монга, для разрабов. Просто приходится ходить ручками в контейнер и делать бд и коллекции

сделайте mongodump нужной вам структуры и при сборке контейнера делайте маунт файла с дампом и монго импорт в контейнере

сделайте mongodump нужной вам структуры и при сборке контейнера делайте маунт файла с дампом и монго импорт в контейнере

в контейнере не надо так делать

задача на 3и строки кода в dockerfile

это попытка занести в докер отвественность которую в докер заносить не стоит

потому что это уровень приложения

в контейнере не надо так делать

почему? это же среда для локальной разработки как я понял, поэтому не криминально

ага, так и есть

почему? это же среда для локальной разработки как я понял, поэтому не криминально

это ещё как криминально

потому что ещё раз: это не отвественность докера

вы ищите «миграции», вероятно ваш ODM в них умеет

в целом согласен, но если в проекте нет миграций как вид, то их внедрение может довольно дорого стоить. хотя в тех. долг записать асап нужно конечно

миграций нет

в итоге управление «миграциями» будут в докере, а это совершенно не то место

в итоге управление «миграциями» будут в докере, а это совершенно не то место

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

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

можно голову отрубить, чтоб не болела — здесь и сейчас

есть приложение, это его ответственность

на уровне приложения сделать seed, сделать отдельный таск/бинарник для прогона сида

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

надо без заполненой стуркутурой )))) т.к какараз и смотрять как даныне падают в монгу после обработки пайплайна

есть приложение, это его ответственность

я согласен с вами, но не забывайте о декомпозиции задачи. есть devops, которому поставлена задача сделать среду для работы программистов на локальных машинах. есть программисты, которые должны в приложение ввести миграции как вид. это 2 разные задачи и предположу что на проекте вторая в принципе не стоит по сей момент со стороны product owner-а)

в третий раз повторяю

это уровень приложения

надо без заполненой стуркутурой )))) т.к какараз и смотрять как даныне падают в монгу после обработки пайплайна

я под структурой имел в виду как раз коллекции и индексы, о которых вы писали вначале

я согласен с вами, но не забывайте о декомпозиции задачи. есть devops, которому поставлена задача сделать среду для работы программистов на локальных машинах. есть программисты, которые должны в приложение ввести миграции как вид. это 2 разные задачи и предположу что на проекте вторая в принципе не стоит по сей момент со стороны product owner-а)

(facepalm)

миграции это не devops, миграции это уровень приложения

раскатывание миграций, это devops

Да и я с этим абсолютно на 100 и даже 200 процентов согласен. Я просто попытался обрисовать ситуацию так как я увидел :)

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

В данном случае к нам за советом по моим предположения обратился как раз devops

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

да ещё раз: не важно кто обратился

Введение системы миграций решит многие проблемы как сейчас так и в будущем

да ещё раз: не важно кто обратился

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

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

Меня не оставляет мысль сделать в БД поле с коротким автоинкрементным ID, для ссылок. Подскажите, как в mongodb проще осуществить автоинкремент, ну или отговорите, если это плохая идея.

Меня не оставляет мысль сделать в БД поле с коротким автоинкрементным ID, для ссылок. Подскажите, как в mongodb проще осуществить автоинкремент, ну или отговорите, если это плохая идея.

https://www.tutorialspoint.com/mongodb/mongodb_autoincrement_sequence.htm

Меня не оставляет мысль сделать в БД поле с коротким автоинкрементным ID, для ссылок. Подскажите, как в mongodb проще осуществить автоинкремент, ну или отговорите, если это плохая идея.

Это очень плохая идея

Это очень плохая идея

Можно подробнее? Почему плохо и какие альтернативы?

Можно подробнее? Почему плохо и какие альтернативы?

Альтернатива ObjectId. Плохо потому что не решает реальной проблемы и требует сложных технических решений в виде отдельного счётчика.

Альтернатива ObjectId. Плохо потому что не решает реальной проблемы и требует сложных технических решений в виде отдельного счётчика.

Родной id останется. Я хочу дополнительное поле.

Да не важно

Хорошо. Какие есть реальные альтернативы для коротких нумерацией сущностей? Будь то пост или заказ, на которые в последствии понадобится сделать прямую ссылку?

Да, разобраться в проблеме и сформулировать требования

Для использования в URI подойдёт objectid, для человеков подойдут любые псевдослучайные идентификаторы, которые используют однозначночитаемые алфавиты

Для использования в URI подойдёт objectid, для человеков подойдут любые псевдослучайные идентификаторы, которые используют однозначночитаемые алфавиты

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

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

Чем это небезопасно то

Разарботчикам надо проходить сеанс психотерапии, чтоб им помогли принять что размер не имеет значения

Людям вообще на ссылки пофиг

Чем это небезопасно то

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

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

Поменяйте уроки