yopp
Монга гарантирует что в случае с распределённым хранением, состояние всех нод рано или поздно будет синхронизировано.
Анатолий
если я удаляю документ - remove, я не ожидаю увидеть его потом снова в результатах find
yopp
И это не нормальное поведение.
yopp
Вы используете устаревшую версию монги
yopp
Обновитесь до 3.6 и проверьте что эта ошибка осталась. Если осталась, мы можем продолжить искать.
Aleksey
@dd_bb как там 4-ка ? ты не следишь ?
yopp
Не-а. Смысла особо нет
yopp
Когда покатят публичные беты, тогда можно смотреть
Aleksey
ну ок. видимо к лету ближе ага ?
yopp
Потом до 4.2 это всё полумеры, пока транзакции шардинг не начнут поддерживать.
yopp
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
Огромное спасибо, еще раз)
️lefrotite
Через компас никуда не подключается из-за ркн. Как быть?
Nick
прокся, впн
Yurii
Привет всем.
Есть интересный вопрос к тем, кто работает с mongoose.
Задача в post(‘save’ вызвать обновления всех записей по некоторому критерию. В this post(‘save’ мы можем получить текущую модель (последний сохраненный и верный документ) и его передать в .updateMany({
}, {
$set: updatedData
}).exec(next);
Но есть случай, когда некоторые поля были удалены, то есть надо делать $unset. Пересчитывать по модели сложно, может кто-то знает как можно достать с модели прошлый запрос или $unset?
Nick
врядли монгус чтото примерное умеет
Yurii
может можно через прототипы достучаться до этого метода?
yopp
а в монгусе нет dirty tracking?
Nick
если открыть доки к монгусу, то там наверняка написано, что он использует предыдущий объект ну или хотя бы расписано как он это делает
Nick
по крайней мере в хибере вроде так
Yurii
yopp
Я правильно понимаю, что у вас есть какая-то модель и есть от неё зависимые. Когда вы обновляете родительский документ, вы за одно хотите сделать $set/$unset по какому-то условию?
Anonymous
Здравствуйте, ребят .
Anonymous
Тут у меня просьба вам . Можете пожалуйста подсказать с какого сайта скачать mongodb на ubuntu 16.04.1
Anonymous
Просто , у меня раньше была в папке и можно было запустить сразу с терминала , а с нэта первый раз устанавливаю
Anonymous
yopp
Yurii
Yurii
и вопрос был как узнать какие поля были в $unset при сохранении текущего документа
Yurii
UPD:
Нашли скрытую функцию $__delta() на модели, но она работает в pre(‘save’ (когда ещё есть изменения) и дает вторым элементом массива как раз запрос, что будет вызван в БД.
Итого переназначаем его в переменную this. и сможем получить в post(‘save’
yopp
похоже на внутренности dirty tracking, да
yopp
насколько я понимаю в js удаляемые поля просто назначаются в undefined
yopp
и потом когда делается дельта состояний модели, скорее всего оно преобразуется в соотвествующий модификатор документа
yopp
Но вообще, это немного странно, что вы пытаетесь сделать
yopp
Это формально нарушает несколько основных принципов ООП. У вас где-то протёк интерфейс, куда не нужно
Yurii
Спасибо. Надеюсь, кому-то будет полезно узнать о
$__delta()
yopp
Попробуйте посмотреть откуда возникает проблема. Не знаю как монгусе, но в некоторых других ORM есть колбэки или возможность переопредлить getter/setter методы модели, чтоб сразу ловить изменине приводящее к деопределению полей
yopp
На мой взгляд ловить это уже перед сохранением, фактически разбирая запрос — очень ненадёжно
yopp
тогда у вас проблема с single source of truth. самый правильный подход синхронизировать через субд, если вы данные в ней храните
yopp
иначе есть шанс получить неверное состояние модели
Viktor
Доброго времени суток, а есть какие-то бест практисы по профилированию монги или тулы готовые?
Petro
Привет, есть список документов в агрегатке, как каждому добавить свое уникальное число?
т.е.
первому документу добавить поле {myNewId: 1}
второму документу добавить поле {myNewId: 2}
n документу добавить поле {myNewId: n}
yopp
yopp
Viktor
Какая задача стоит?
У девелопера пару раз упала монга с OutOfMemory. Посмотрел логи, такое ощущение, что по одному документу тянется из курсора долгое время, а потом разваливается. Хочу погонять и поискать какой запрос или какой долгоживущий курсор роняет монгу. В логах монги перед крашем куча подобного:
COMMAND [conn2] command xxx.User command: getMore { getMore: 409911195575, collection: "User" } originatingCommand: { aggregate: "User", pipeline: [], cursor: {} } planSummary: COLLSCAN cursorid:409911195575