Или я тупой или сани не едут :) const userSchema = new Schema({ phone: { type: String, validate: { validator: function(v) { return /\d{3}-\d{3}-\d{4}/.test(v); }, message: props => `${props.value} is not a valid phone number!` }, required: [true, 'User phone number required'] } }); В их примерах у ключа пропсами прописывается валидация и тд. Но я же не могу заменитьусловную стрингу своим объектом вместо type

Или я тупой или сани не едут :) const userSchema = new Schema({ phone: { type: String, validate: { validator: function(v) { return /\d{3}-\d{3}-\d{4}/.test(v); }, message: props => `${props.value} is not a valid phone number!` }, required: [true, 'User phone number required'] } }); В их примерах у ключа пропсами прописывается валидация и тд. Но я же не могу заменитьусловную стрингу своим объектом вместо type

Привет, подскажите, пожалуйста, как хранить цены продукта в монге? Т.е цена может быть разной в зависимости от времени, у цены есть поля 1) цена 2) дата начала действия 3) дата окончания действия Как это можно организовать ума не приложу. Чтобы допустим при запросе на клиент подтягивалась только актуальная цена

Привет, подскажите, пожалуйста, как хранить цены продукта в монге? Т.е цена может быть разной в зависимости от времени, у цены есть поля 1) цена 2) дата начала действия 3) дата окончания действия Как это можно организовать ума не приложу. Чтобы допустим при запросе на клиент подтягивалась только актуальная цена

У меня есть такое... Есть некая сущность с ценой. У неё есть правила. Прямо вот встроенный список документов. Почти в том формате, в каком у тебя показано. Но у меня специфика в том, что мне не нужно искать текущие цены и как-то с ними работать. Достаточно уже в коде проекта перебрать правила и найти текущую. За целостность так же отвечает код приложения, а не БД.

тут скорее крон какой-то для сканирования коллекций на просроченные цены

Т.е на бэке идёт поиск цены? Я думал всю историю цен хранить в документе продукта и на бэке уже как то фильтровать

Загуглю, не знаю что это, я в монге прям новичек, понаех из MySQL)))

Понятно. А не посоветуете какие нибудь источники, которыми пользовались при проектировании?

Опыт. 🙂 К сожалению, не посоветую. Разве что "книжку с кабанчиком"...

Опыт. 🙂 К сожалению, не посоветую. Разве что "книжку с кабанчиком"...

Вопрос про агрегации. Есть запрос типа, условно: values = [{'key1': value1, 'key2': value2}, {'key1': value3, 'key2': value4}] match: {or: values} по элементам из values - по каждому могут быть много документов. Можно ли как то вывести только каждый 1 документ из подходящий по условие в values. Условно, как если было бы много запросов findone по values - из подходящих под условие нужен только 1 документ вообщем

в агрегации $filter для отсеивания нужных элементов, потом через $slice взять один элемент

Нет, фильтровать ничего не надо, если такие документы нашлись, у них надо просто взять по 1 документу- из кажого документа у него 2 поля нужны. Условно, нужны те кто вообще нашлись

тогда просто не понятно что вам надо

Документ: k1:v1, k2:v2, k3:v3. И таких с отличным полем k3 - условно 100 Документ: k1:v4, k2:v5, k3:v6 Я через match or ищу сразу по всем нужным k1, k2 Но мне из каждой группы нужно по 1.

что значит "нужно по одному"? limit(1) и вот у вас один

Если после лимит сделать - то будет просто 1 первый документ

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

Не понимаю как стейджи будут выглядеть. И опять про слайс монга же все равно «подгрузит» все документы из каждой группы, и потом только слайс

а у вас другого варианта нет, на стороне базы будет подгрузка всех данных с дисков. Разве что планировщик чтонить наколдует и чтото проигнорирует

То есть find с лимитом 1 оно же- findone - тянет все документы?

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

Да нет. По другому попробую. Как завернуть 1000 findone по одной паре ключей но для разных значений в этих ключах в аггрегацию.

Так матч потянет все документы для каждой пары

Первый любой - лимит 1

вот тогда вместо $push, $first

вопрос ко всем - не встречал ли кто-то попыток создать орм для носкул? или всё-таки, были такие отчаянные ребята?

Ага, first

но далеко не факт что монга не прочитает все остальные

вопрос: иногда ловлю такую ошибку в аппе "pymongo.errors.OperationFailure: text index required for $text query (no such collection 'name_db.name_collection'), full error: {'ok': 0.0, 'errmsg': "text index required for $text query (no such collection 'name_db.name_collection')", 'code': 27, 'codeName': 'IndexNotFound'}" т.е. ошибка - нет такой коллекции корневая, как я понял, только коллекция существует. как такое может вообще быть? так как у меня "много записей", я обновляю всю коллекцию путём переименования новой, в имя старой (что бы доступность данных была бесперебойной), но эта ошибка не совпадет с временем обновления (перезаписи коллекции). п.с. name_db.name_collection - я изменил специально имя, не обращайте на это внимания

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

индекс сразу создаётся после перезаписи старой коллекции. то есть: 1. существует старая коллекция, в ней изменяется много данных (порядка 70%) 2. что бы не делать данные недоступными "долгое время" (критично более 1 минуты), я в фоне создаю новую коллекцию с данными: данные старой коллекции + данные обновлённые + новые данные 3. получаю коллекцию 2_новую 4. в один момент, как только 2_новая - готова, я удаляю старую, а новую переименовываю в старое название 5. естественно в 2_новая индекс уже создан

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

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

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

Создание индекса на больших объемах может много времени занимать. Вы можете попробовать создавать индексы до вставки данных. Данные будут добавляться чуть медленнее, но при этом индекс сразу будет доступен для использования

Создание индекса на больших объемах может много времени занимать. Вы можете попробовать создавать индексы до вставки данных. Данные будут добавляться чуть медленнее, но при этом индекс сразу будет доступен для использования

Да. Я практикую такой способ. Но это дисковые операции и часто диск бутлнек для вставки. Практическим способом определил, на своих серверах, вставка без индекса большого массива данных(~12 Тб) занимает у меня без индекса около 30 часов. С индексом около 50.

с версии 4.2, все индексы создаются асинхронного, по этому createIndex() вернёт ответ практически сразу, не ожидая завершения создания индекса

ну у меня не 12 Тб) но много записей, порядка 150 млн, но они лёгкие

Тогда этот вариант вам должен подойти