yopp
Монга гарантирует что в случае с распределённым хранением, состояние всех нод рано или поздно будет синхронизировано.
Анатолий
если я удаляю документ - remove, я не ожидаю увидеть его потом снова в результатах find
yopp
И это не нормальное поведение.
yopp
Вы используете устаревшую версию монги
yopp
Обновитесь до 3.6 и проверьте что эта ошибка осталась. Если осталась, мы можем продолжить искать.
Aleksey
@dd_bb как там 4-ка ? ты не следишь ?
yopp
Не-а. Смысла особо нет
yopp
Когда покатят публичные беты, тогда можно смотреть
Aleksey
ну ок. видимо к лету ближе ага ?
yopp
Потом до 4.2 это всё полумеры, пока транзакции шардинг не начнут поддерживать.
yopp
Вообще хочу шарженные индексы. :(
yopp
Но без синхронизации internal id между нодами, это не совсем целесообразно.
Nick
что ты подразумеваешь под "шарженными индексами"?
yopp
Чтоб можно было отдельно шардить данные и отдельно шардить индексы
yopp
Одна из крутых особенностей hypertable заключается в том, что у каждой гипертаблицы свой собственный индекс.
yopp
Т.е. тебе не надо держать в памяти ненужные куски деревьев
yopp
Если добавить возможность разбивать индексы на чанки, по сути можно получить похожий механизм.
yopp
Но я сомневаюсь что до 5.0 какие-то существенные улучшения будут
vitalii
парни , кто то шарит , как пройти все значения мыла ? сделать forIn а в нем findOne ? но так же нужна же проверка если ниодного нет мыла 7 или есть проще чего то User.findOne ({$or: [{email: profile.emails[0].value},{id_social_network: profile.id}]}, function (err, user) {}
Noname
Ребят, прошу помощи, так как очень горит, а опыта с aggregate - мало. Есть такая схема: { email: { type: String, unique: true }, referals: [{ type: mongoose.Schema.Types.ObjectId, ref: "User" }], transactions: [{ type: mongoose.Schema.Types.ObjectId, ref: "Transaction" }] } надо вывести все транзакции всех рефералов, а у моих кривых ручек не получается применить $graphLookup к одному пользователю, никак не хочет работать после $match буду безумно благодарен любой помощи!
yopp
Покажите текущую агрегацию
Noname
db.users.aggregate( [ { "$match" : { "ref_id" : 10083298 } }, { "$graphLookup" : { "from" : "users", "startWith" : "referals", "connectFromField" : "ref_id", "connectToField" : "transactions", "as" : "test" } } ], { "allowDiskUse" : false } );
yopp
ref_id это аттрибут модели User?
yopp
и такой-же аттрибут есть в Transaction?
Noname
ref_id -атрибут только модели User. В модели Transaction отсутсвует
Noname
Но в транзакции есть ссылка по атрибуту owner
yopp
Вам в итоге надо получить транзакции или id транзакций?
Noname
Сумму по атрибуту , во всех полученных транзакциях….
yopp
"startWith" : "referals" имелось ввиду $referals наверное
yopp
Но вообще сначала разбейте эту операцию для себя по шагам
yopp
Скорее всего вам нужно сделать unwind по referals. Не уверен что $graphLookup корректно будет работать с массивами
Noname
то есть получается $graphLookup->дерево пользователей ->транзакции->$match->$project->$group
yopp
а зачем ещё $match?
yopp
И будьте внимательны, allowDiskUse не влияет на graphLookup. Там сторого 100мб ограничение и его никак не обойти
yopp
Так что яб не выбирал транзакции через graphLookup. Для того чтоб выбрать из transaction только нужные, у вас уже есть owner. Так что я бы свёл бы к двум задачам: получить список индентификаторов рефереалов, а потом уже через $lookup вытащить нужные транзакции.
yopp
но вот был бы у вас materialized path, вы бы смогли в один запрос это сделать :)
Noname
Спасибо!
Noname
но вот был бы у вас materialized path, вы бы смогли в один запрос это сделать :)
я к этому тоже пришел, и явно буду «мигрировать» всю базу все выходные)
Noname
Огромное спасибо, еще раз)
️lefrotite
Через компас никуда не подключается из-за ркн. Как быть?
Nick
прокся, впн
Yurii
Привет всем. Есть интересный вопрос к тем, кто работает с mongoose. Задача в post(‘save’ вызвать обновления всех записей по некоторому критерию. В this post(‘save’ мы можем получить текущую модель (последний сохраненный и верный документ) и его передать в .updateMany({ }, { $set: updatedData }).exec(next); Но есть случай, когда некоторые поля были удалены, то есть надо делать $unset. Пересчитывать по модели сложно, может кто-то знает как можно достать с модели прошлый запрос или $unset?
Nick
врядли монгус чтото примерное умеет
Yurii
врядли монгус чтото примерное умеет
ну он как-то генерирует запрос на момент save
Yurii
может можно через прототипы достучаться до этого метода?
yopp
а в монгусе нет dirty tracking?
Nick
если открыть доки к монгусу, то там наверняка написано, что он использует предыдущий объект ну или хотя бы расписано как он это делает
Nick
по крайней мере в хибере вроде так
Yurii
а в монгусе нет dirty tracking?
нашел такое, но кажется оно не то, что надо http://mongoosejs.com/docs/api.html#hydrate_hydrate
yopp
Я правильно понимаю, что у вас есть какая-то модель и есть от неё зависимые. Когда вы обновляете родительский документ, вы за одно хотите сделать $set/$unset по какому-то условию?
Anonymous
Здравствуйте, ребят .
Anonymous
Тут у меня просьба вам . Можете пожалуйста подсказать с какого сайта скачать mongodb на ubuntu 16.04.1
Anonymous
Просто , у меня раньше была в папке и можно было запустить сразу с терминала , а с нэта первый раз устанавливаю
Yurii
Я правильно понимаю, что у вас есть какая-то модель и есть от неё зависимые. Когда вы обновляете родительский документ, вы за одно хотите сделать $set/$unset по какому-то условию?
есть функционал по обновлению документа. Но иногда, обновление документа должно обновить документы, которые по неким критериям смежные и обновляемым. Когда идет updateMany c $set все хорошо, а вот $unset без пересчёта не сделать. Вот и хотелось взять с save() набор полей, которые надо $unset
Yurii
не очень понимаю последнюю часть про «без пересчёта не сделать» и «хотелось взять с save() набор полей»
чтобы удалить поле из документа, надо его передать в $unset, если передать в $set - то он не удалиться
Yurii
и вопрос был как узнать какие поля были в $unset при сохранении текущего документа
Yurii
UPD: Нашли скрытую функцию $__delta() на модели, но она работает в pre(‘save’ (когда ещё есть изменения) и дает вторым элементом массива как раз запрос, что будет вызван в БД. Итого переназначаем его в переменную this. и сможем получить в post(‘save’
yopp
похоже на внутренности dirty tracking, да
yopp
насколько я понимаю в js удаляемые поля просто назначаются в undefined
yopp
и потом когда делается дельта состояний модели, скорее всего оно преобразуется в соотвествующий модификатор документа
Yurii
насколько я понимаю в js удаляемые поля просто назначаются в undefined
есть нюансы, монгус как раз в post(‘save’ не вернет тебе поле с значением undefined, так как оно ушло в $unset 😅
yopp
Но вообще, это немного странно, что вы пытаетесь сделать
yopp
Это формально нарушает несколько основных принципов ООП. У вас где-то протёк интерфейс, куда не нужно
Yurii
Это формально нарушает несколько основных принципов ООП. У вас где-то протёк интерфейс, куда не нужно
не спорю, но это то решение, под задачу которую поставили. Другие «правильные» решения, сейчас, увы не подходят.
Yurii
Спасибо. Надеюсь, кому-то будет полезно узнать о $__delta()
yopp
Попробуйте посмотреть откуда возникает проблема. Не знаю как монгусе, но в некоторых других ORM есть колбэки или возможность переопредлить getter/setter методы модели, чтоб сразу ловить изменине приводящее к деопределению полей
yopp
На мой взгляд ловить это уже перед сохранением, фактически разбирая запрос — очень ненадёжно
Yurii
Попробуйте посмотреть откуда возникает проблема. Не знаю как монгусе, но в некоторых других ORM есть колбэки или возможность переопредлить getter/setter методы модели, чтоб сразу ловить изменине приводящее к деопределению полей
там проблема в другом, что надо синхронизировать между собой документы. Можно по очереди вытягивать документ, сравнивать и сохранять, но это будет затратно, а так мы знаем точно что надо переписать (установить и удалить) и можно это сделать одним запросом через updateMany. Не говорю, что это хорошо и надежно.
yopp
тогда у вас проблема с single source of truth. самый правильный подход синхронизировать через субд, если вы данные в ней храните
yopp
иначе есть шанс получить неверное состояние модели
Viktor
Доброго времени суток, а есть какие-то бест практисы по профилированию монги или тулы готовые?
Petro
Привет, есть список документов в агрегатке, как каждому добавить свое уникальное число? т.е. первому документу добавить поле {myNewId: 1} второму документу добавить поле {myNewId: 2} n документу добавить поле {myNewId: n}
Viktor
Какая задача стоит?
У девелопера пару раз упала монга с OutOfMemory. Посмотрел логи, такое ощущение, что по одному документу тянется из курсора долгое время, а потом разваливается. Хочу погонять и поискать какой запрос или какой долгоживущий курсор роняет монгу. В логах монги перед крашем куча подобного: COMMAND [conn2] command xxx.User command: getMore { getMore: 409911195575, collection: "User" } originatingCommand: { aggregate: "User", pipeline: [], cursor: {} } planSummary: COLLSCAN cursorid:409911195575