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

Привет! Я пытался разобраться с предлагаемой вами схемой и немного запутался (в том числе ознакомился с ссылками, которвые вы давали). Сразу извиняюсь за глупые вопросы (я дизайнер). У меня получается примерно такой код, но он не работает. Скажите, я в правильном направлении думаю? exports.weeklySummary = function(cb) { db.get().collection(config.collectionConnect).aggregate([ { $project: { _id: "$_id", address: { _id: "$_id", City: "$City", Street: "$Street"}, attributes: { _id: "$_id", Temperature: "$Temperature", Pressure: "$Pressure"} } }, { $group: { _id: "$_id", // date: Date(), address_id: { "$_id": "$address" }, attribute_id: { "$_id": "$attributes" }, measurements: [ { date: "$Date", value1: "$Temperature", value2: "$Pressure" } ], min: { $min: "$value1", $min: "$value2" }, max: { $max: "$value1", $max: "$value2" }, // count: { $count: "$measurements" } // sum: {}, // avg: {} } } ]).next(function(err, doc) { cb(err, doc); }); };

А бросьте пример на play.db-ai.co

Закинул: https://play.db-ai.co/m/Xe-JMmjklgABiODu/edit?key=HWQgTvvjdbU

Закинул: https://play.db-ai.co/m/Xe-JMmjklgABiODu/edit?key=HWQgTvvjdbU

У меня вопрос в документе есть массив объектов, и нужно что бы в этом масиве были только объекты с уникальными id, как такое можно сделать на уровне схемы валидации, Мне ясно как сделать что бы элементы масива были уникальны, а как что бы в массиве были объекты с определенным уникальным полем

Закинул: https://play.db-ai.co/m/Xe-JMmjklgABiODu/edit?key=HWQgTvvjdbU

или вы хотите существующие документы сконвертировать в новый формат?

Я хотел попробовать использовать предлагаемую вами схему, но у меня возникли проблемы с её чтением и небольшой опыт работы с Монгой — стали для меня препятсвием

Я хотел попробовать использовать предлагаемую вами схему, но у меня возникли проблемы с её чтением и небольшой опыт работы с Монгой — стали для меня препятсвием

массив объектов к примеру {id: 232, name: '32323'} .... и в массиве id должно быть уникально

пока вы далеко не уехали я вам рекомендую поменять схему. группируйте ваши значения в один документ на час { _id: <ObjectID>, date: Date("округлить до начала часа"), address_id: <ObjectID>, // из коллекции addresses, где уже {_id:, Street:, Address:} attribute_id: <ObjectID>, // из коллекции attributes, где {_id, type: "Temperature"} measurements: [ { date: Date("реальная дата"), value: <значение> } ], min: <минимальное_значение>, max: <максимальное_значени>, count: <количество записей в measurements>, sum: <сумма value из measurements>, avg: <$div: [$sum, $count] }

Но у меня всё пишется в одну коллекцию и она имеет такой вид документа: { "_id": "5da9fa2ef1c2fd2070d320fe", "Date": 1571431517, "City": "City", "Street": "Street", "Temperature": 25.5, "Pressure": 748.8 }

Вот этого и нужно избегать

чуток подправил и поигрался с вашим запросом https://play.db-ai.co/m/Xe-JMmjklgABiODu

чуток подправил и поигрался с вашим запросом https://play.db-ai.co/m/Xe-JMmjklgABiODu

Есть тупой вопрос, очееееень тупой вопрос: as far as I understand операция findAndModify является атомарной операцией, накладывающей оптимистичный лок на документ, с которым она работает, ведь так? (поправьте меня если это не так, возможно, я снова протупилось по месту в документации) А если допустить, что findAndModify производится последовательно по одной коллекции, то выгоднее ли будет в данном случае использовать update? Просто сталкиваюсь порой с ситуацией вот такого. рода: по system.profile данная операция порой проседает, потому что производится по нескольку раз.

update это и есть findAndModify

т.е. вы группируете значения одного аттрибута (температуры, давления) по одному адресу за какое-то время

Разница только в том, что update умеет в multi, не умеет в сортировку и не возвращает обновлённый документ

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

Потому, что например по slowlogs и по логам базы иногда просачивается вот такое: происходит findAndModify на коллекцию, и следующие за ним findAndModify оказываются залочены им (якобы), но ранее операций, который могут накладывать лок на уровне базы/коллекции нет попросту.

Залочены это вы как определили?

да

read запросы ждут?