а есть команда на обрубание старых сессий коннектов - чтобы завершили запросы и открылись заново?

Нет, опять-же это не ваша забота.

Это просто архитектура хранилища

ага. только в доках об этом нюансе ни слова =((

Ваша проблема либо в каком-то специфичном баге в монге (маловероятно, но вы можете это проверить обновившись 3.6) либо в запросах/кешировании.

вот про кэш ещё верится ))

Не в монге, а в вашем приложении.

Монга не даёт вам никаких низкоуровневых ручек. Они вам не нужны.

ага. только в доках об этом нюансе ни слова =((

О каком?

Монга гарантирует вам целостность представления только в рамках одного документа.

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

если я удаляю документ - remove, я не ожидаю увидеть его потом снова в результатах find

И это не нормальное поведение.

Вы используете устаревшую версию монги

Обновитесь до 3.6 и проверьте что эта ошибка осталась. Если осталась, мы можем продолжить искать.

@dd_bb как там 4-ка ? ты не следишь ?

Не-а. Смысла особо нет

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

ну ок. видимо к лету ближе ага ?

Потом до 4.2 это всё полумеры, пока транзакции шардинг не начнут поддерживать.

ну ок. видимо к лету ближе ага ?

Да, наверное.

Вообще хочу шарженные индексы. :(

Но без синхронизации internal id между нодами, это не совсем целесообразно.

что ты подразумеваешь под "шарженными индексами"?

Чтоб можно было отдельно шардить данные и отдельно шардить индексы

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

Т.е. тебе не надо держать в памяти ненужные куски деревьев

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

Но я сомневаюсь что до 5.0 какие-то существенные улучшения будут

парни , кто то шарит , как пройти все значения мыла ? сделать forIn а в нем findOne ? но так же нужна же проверка если ниодного нет мыла 7 или есть проще чего то User.findOne ({$or: [{email: profile.emails[0].value},{id_social_network: profile.id}]}, function (err, user) {}

Ребят, прошу помощи, так как очень горит, а опыта с aggregate - мало. Есть такая схема: { email: { type: String, unique: true }, referals: [{ type: mongoose.Schema.Types.ObjectId, ref: "User" }], transactions: [{ type: mongoose.Schema.Types.ObjectId, ref: "Transaction" }] } надо вывести все транзакции всех рефералов, а у моих кривых ручек не получается применить $graphLookup к одному пользователю, никак не хочет работать после $match буду безумно благодарен любой помощи!

Покажите текущую агрегацию

db.users.aggregate( [ { "$match" : { "ref_id" : 10083298 } }, { "$graphLookup" : { "from" : "users", "startWith" : "referals", "connectFromField" : "ref_id", "connectToField" : "transactions", "as" : "test" } } ], { "allowDiskUse" : false } );

ref_id это аттрибут модели User?

и такой-же аттрибут есть в Transaction?

ref_id -атрибут только модели User. В модели Transaction отсутсвует

Но в транзакции есть ссылка по атрибуту owner

Вам в итоге надо получить транзакции или id транзакций?

Сумму по атрибуту , во всех полученных транзакциях….

"startWith" : "referals" имелось ввиду $referals наверное

Но вообще сначала разбейте эту операцию для себя по шагам

Скорее всего вам нужно сделать unwind по referals. Не уверен что $graphLookup корректно будет работать с массивами

то есть получается $graphLookup->дерево пользователей ->транзакции->$match->$project->$group

а зачем ещё $match?

И будьте внимательны, allowDiskUse не влияет на graphLookup. Там сторого 100мб ограничение и его никак не обойти

Так что яб не выбирал транзакции через graphLookup. Для того чтоб выбрать из transaction только нужные, у вас уже есть owner. Так что я бы свёл бы к двум задачам: получить список индентификаторов рефереалов, а потом уже через $lookup вытащить нужные транзакции.

но вот был бы у вас materialized path, вы бы смогли в один запрос это сделать :)

Спасибо!

но вот был бы у вас materialized path, вы бы смогли в один запрос это сделать :)

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

Огромное спасибо, еще раз)

Через компас никуда не подключается из-за ркн. Как быть?

прокся, впн

Привет всем. Есть интересный вопрос к тем, кто работает с mongoose. Задача в post(‘save’ вызвать обновления всех записей по некоторому критерию. В this post(‘save’ мы можем получить текущую модель (последний сохраненный и верный документ) и его передать в .updateMany({ }, { $set: updatedData }).exec(next); Но есть случай, когда некоторые поля были удалены, то есть надо делать $unset. Пересчитывать по модели сложно, может кто-то знает как можно достать с модели прошлый запрос или $unset?

врядли монгус чтото примерное умеет

врядли монгус чтото примерное умеет

ну он как-то генерирует запрос на момент save

может можно через прототипы достучаться до этого метода?

а в монгусе нет dirty tracking?

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

по крайней мере в хибере вроде так

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

не нашел

а в монгусе нет dirty tracking?

нашел такое, но кажется оно не то, что надо http://mongoosejs.com/docs/api.html#hydrate_hydrate

Я правильно понимаю, что у вас есть какая-то модель и есть от неё зависимые. Когда вы обновляете родительский документ, вы за одно хотите сделать $set/$unset по какому-то условию?

Здравствуйте, ребят .

Тут у меня просьба вам . Можете пожалуйста подсказать с какого сайта скачать mongodb на ubuntu 16.04.1

Тут у меня просьба вам . Можете пожалуйста подсказать с какого сайта скачать mongodb на ubuntu 16.04.1

https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/#install-mongodb-community-edition

ERROR: S client not available

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

Я правильно понимаю, что у вас есть какая-то модель и есть от неё зависимые. Когда вы обновляете родительский документ, вы за одно хотите сделать $set/$unset по какому-то условию?

есть функционал по обновлению документа. Но иногда, обновление документа должно обновить документы, которые по неким критериям смежные и обновляемым. Когда идет updateMany c $set все хорошо, а вот $unset без пересчёта не сделать. Вот и хотелось взять с save() набор полей, которые надо $unset

https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/#install-mongodb-community-edition

Спасибо

есть функционал по обновлению документа. Но иногда, обновление документа должно обновить документы, которые по неким критериям смежные и обновляемым. Когда идет updateMany c $set все хорошо, а вот $unset без пересчёта не сделать. Вот и хотелось взять с save() набор полей, которые надо $unset

не очень понимаю последнюю часть про «без пересчёта не сделать» и «хотелось взять с save() набор полей»

не очень понимаю последнюю часть про «без пересчёта не сделать» и «хотелось взять с save() набор полей»

чтобы удалить поле из документа, надо его передать в $unset, если передать в $set - то он не удалиться

и вопрос был как узнать какие поля были в $unset при сохранении текущего документа

UPD: Нашли скрытую функцию $__delta() на модели, но она работает в pre(‘save’ (когда ещё есть изменения) и дает вторым элементом массива как раз запрос, что будет вызван в БД. Итого переназначаем его в переменную this. и сможем получить в post(‘save’

похоже на внутренности dirty tracking, да

насколько я понимаю в js удаляемые поля просто назначаются в undefined

и потом когда делается дельта состояний модели, скорее всего оно преобразуется в соотвествующий модификатор документа

насколько я понимаю в js удаляемые поля просто назначаются в undefined

есть нюансы, монгус как раз в post(‘save’ не вернет тебе поле с значением undefined, так как оно ушло в $unset ?

Но вообще, это немного странно, что вы пытаетесь сделать

Это формально нарушает несколько основных принципов ООП. У вас где-то протёк интерфейс, куда не нужно

Это формально нарушает несколько основных принципов ООП. У вас где-то протёк интерфейс, куда не нужно

не спорю, но это то решение, под задачу которую поставили. Другие «правильные» решения, сейчас, увы не подходят.

Спасибо. Надеюсь, кому-то будет полезно узнать о $__delta()

Попробуйте посмотреть откуда возникает проблема. Не знаю как монгусе, но в некоторых других ORM есть колбэки или возможность переопредлить getter/setter методы модели, чтоб сразу ловить изменине приводящее к деопределению полей

На мой взгляд ловить это уже перед сохранением, фактически разбирая запрос — очень ненадёжно

Попробуйте посмотреть откуда возникает проблема. Не знаю как монгусе, но в некоторых других ORM есть колбэки или возможность переопредлить getter/setter методы модели, чтоб сразу ловить изменине приводящее к деопределению полей

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

тогда у вас проблема с single source of truth. самый правильный подход синхронизировать через субд, если вы данные в ней храните

иначе есть шанс получить неверное состояние модели

Доброго времени суток, а есть какие-то бест практисы по профилированию монги или тулы готовые?

Привет, есть список документов в агрегатке, как каждому добавить свое уникальное число? т.е. первому документу добавить поле {myNewId: 1} второму документу добавить поле {myNewId: 2} n документу добавить поле {myNewId: n}

Доброго времени суток, а есть какие-то бест практисы по профилированию монги или тулы готовые?

Какая задача стоит?

Привет, есть список документов в агрегатке, как каждому добавить свое уникальное число? т.е. первому документу добавить поле {myNewId: 1} второму документу добавить поле {myNewId: 2} n документу добавить поле {myNewId: n}

$projection: { myNewId: {$sum: 1} }

Какая задача стоит?

У девелопера пару раз упала монга с OutOfMemory. Посмотрел логи, такое ощущение, что по одному документу тянется из курсора долгое время, а потом разваливается. Хочу погонять и поискать какой запрос или какой долгоживущий курсор роняет монгу. В логах монги перед крашем куча подобного: COMMAND [conn2] command xxx.User command: getMore { getMore: 409911195575, collection: "User" } originatingCommand: { aggregate: "User", pipeline: [], cursor: {} } planSummary: COLLSCAN cursorid:409911195575

У девелопера пару раз упала монга с OutOfMemory. Посмотрел логи, такое ощущение, что по одному документу тянется из курсора долгое время, а потом разваливается. Хочу погонять и поискать какой запрос или какой долгоживущий курсор роняет монгу. В логах монги перед крашем куча подобного: COMMAND [conn2] command xxx.User command: getMore { getMore: 409911195575, collection: "User" } originatingCommand: { aggregate: "User", pipeline: [], cursor: {} } planSummary: COLLSCAN cursorid:409911195575

https://github.com/rueckstiess/mtools/wiki/mlogvis

плюс встроеный профайлер с большим порогом срабатывания

Понял, начну с этого, спасибо. А долгоживущие курсоры также можно потрекать в профайлере?

Понял, начну с этого, спасибо. А долгоживущие курсоры также можно потрекать в профайлере?

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

У девелопера пару раз упала монга с OutOfMemory. Посмотрел логи, такое ощущение, что по одному документу тянется из курсора долгое время, а потом разваливается. Хочу погонять и поискать какой запрос или какой долгоживущий курсор роняет монгу. В логах монги перед крашем куча подобного: COMMAND [conn2] command xxx.User command: getMore { getMore: 409911195575, collection: "User" } originatingCommand: { aggregate: "User", pipeline: [], cursor: {} } planSummary: COLLSCAN cursorid:409911195575

как интересно

$projection: { myNewId: {$sum: 1} }

ммм, нет, так чот не катит

как интересно

Ага, прод не упал, но звоночек некрасивый, поэтому и расследую