yopp
это не проблема в монге, это проблема у вас в коде :)
yopp
я плохо на js говорю, но я так понимаю await это синхронная операция
yopp
а занчит withTransation висит пока await #2 не разблокирует
yopp
и тут монга совершенно не причём. откуда она знает почему №1 не комиттится
yopp
а она не комиттится потому что №2 залочен на транзакцию
Ilya
а она не комиттится потому что №2 залочен на транзакцию
она пытается выполнить изменения залоченного дока, и не получается?
yopp
да, потому что №1 не снимает блокировку
yopp
это даже не deadlock, а под капотом у монги это livelock )
yopp
потому что #2 деает retry под капотом
yopp
вам нужно вынести №2 из контекста транзакции или делать его асинхронно, чтоб транзакция могла завершится
Ilya
аааааааааааааааааааааа
Ilya
осознал)
Ilya
спасибо за пояснение, я еще видос гляну)
yopp
посмотрите видео, али там популярно очень объясняет про поведение монги в случае конфликтов
Ilya
получается, долгое время ждет не транзакция, а операция №2, в безуспешных попытках выполниться?
yopp
ждёт ваш код :)
Askhat
Разве при изменении полей лочится сама дока?
Ilya
понял, вот это и сбило меня с толку
Askhat
В новых версиях чё-то там говорили про field lock
Artem
Кто может сказать почему если делать $inc для поля типа bsonType: 'int' получаем Document failed validation а если сделать поле double то все будет ок
Дмитрий
Вечер добрый, возник вопрос по findOneAndUpdate
.findOneAndUpdate(
{ _id: args.id, items: { $elemMatch: { _id: "5ddbc00ac30b1311c388544e" } } },
{ $set: { "items.$.name": "Hello" } },
{ new: true}
)
в данном примере происходит поиск сначала по id-шнику документа, следом по id-шнику элемента из sybarray с последующей установкой нового значения.
Собственно это работает, но, хочется делать поиск не по id-шнику из sybarray, а по индексу элемента в sybarray.
Такая конструкция:
{ _id: args.id, items: { $arrayElemAt: ["$items", 0] } }
не работает :(
yopp
Кто может сказать почему если делать $inc для поля типа bsonType: 'int' получаем Document failed validation а если сделать поле double то все будет ок
А как у вас валидаторы для документа выглядят?
yopp
В новых версиях чё-то там говорили про field lock
Может быть вы путаете с field level encryption?
yopp
Так-то, в монге нет «поля». Документ обновляется в любом случае целиком
yopp
Потому что документ это просто bson blob
Дмитрий
$items.0
Это ведь должно быть аргументом поиска для arrayElemAt?
{ _id: args.id, items: { $arrayElemAt: [$items.0 ]} }
не работает, жалуясь на синтаксис.
yopp
Нет
yopp
“items.0”: x
yopp
https://docs.mongodb.com/manual/core/document/#dot-notation
Дмитрий
Нет
Я кажется только что прозрел - мне не нужно искать элемент по индексу и вытаскивать его ( для последующей замены в нем ), достаточно просто произвести замену в элементе :)
Спасибо.
Artem
А как у вас валидаторы для документа выглядят?
Проблема решена, трабл был в относительно оболочки с которой слался реквест
Дмитрий
“items.0”: x
Полного прозрения увы не достиг, теперь в связке не работает $ и нельзя применять конструкцию:
{ $set: { "items.$.name": "Hello" } },
вариант с
const element = "items" + "." + args.position + "." + "name";
и последующей попыткой:
{ $set: { element: "Hello" } },
тоже не работает
Дмитрий
т.е. я не могу передать для findOneAndUpdate индекс элемента, который мне нужно обновить.
yopp
Вам не нужен positional operator $, если вы знаете индекс
yopp
Вставьте индекс туда, где у вас сейчас стоит $
Дмитрий
Проблема в том, что "items.0.name" экранировано, и можно либо четко обозначить элемент, который меняется, и это работает, либо как раз как я теперь думать как иначе подставить это значение, предполагаю, что все же нужно применять поиск по индексу, и в этом случае заработает $
Дмитрий
Не факт, что это так оставлю, зато работает :)
const element = await editor.findOne(
{ _id: args.id },
{ items: { $slice: [args.position, 1] } }
);
const update = await editor
.findOneAndUpdate(
{
_id: args.id,
items: { $elemMatch: { _id: element.items[0]._id } }
},
{ $set: { "items.$.name": args.name } },
{
new: true
}
)
Александр
Народ подскажите в чем проблема. Временная колеция, указал таминг 6 часов, потом переделал на 2, записи не удаляются. Что нужно сделать, чтобы поправить? Убить колекцию не вариант, боевой сервер.
yopp
вы иметее ввиду у вас в коллеции есть ttl индекс?
Александр
вы иметее ввиду у вас в коллеции есть ttl индекс?
я так понемаю ее надо перенидексировать?
yopp
Вы поменяли expireAfterSeconds с 6 часов на 2 часа?
yopp
через collMod или пересоздали индекс?
Александр
я использовал mongoose в приложении, в нем указал, другое значение
yopp
скорее всего индекс не пересоздался
yopp
можно просто через collMod https://docs.mongodb.com/manual/reference/command/collMod/#index
yopp
либо удалить существующий индекс и создать новый
yopp
если документов не очень много
Andrew
я плохо на js говорю, но я так понимаю await это синхронная операция
А я думал, у вас V8 на авке )
Александр
можно просто через collMod https://docs.mongodb.com/manual/reference/command/collMod/#index
спасибо, буду рыть в этом направлении
Anonymous
Привет всем!
Монга рвёт соединение с клиентом, если долго не было запросов?
yopp
не должна
yopp
но это сложный вопрос, в спецификации явно не указано поведение
yopp
в некоторых драйверах есть вот такая вот опция: https://docs.mongodb.com/manual/reference/connection-string/#urioption.maxIdleTimeMS
yopp
но это со стороны драйвера
Ivan
yopp
яжговорил™
yopp
но это старая политика
yopp
если дропнули, то бэкпорта не будет
yopp
наверное, за деньги можно приватных патчей заказать
Danil
Ilya
Господа, подскажите, а как в монге принято работать с конкурентными запросами?
Т.е. если у меня есть сущность, которую два запроса могут квазиодновременно изменить, как обычно с этим борются?
Ilya
Иными словами, хочу чтобы не произошло гонки при изменении одного документа
Yaroslav
Господа, подскажите, а как в монге принято работать с конкурентными запросами?
Т.е. если у меня есть сущность, которую два запроса могут квазиодновременно изменить, как обычно с этим борются?
Если в ноде то async await, если go то gorutine, но всеравно проритет сохранения за последним запросом, иными словами если 100 запросов единовременно на сохранение или апдейт одного поля, то результатом будет то, что выполнит я последним, в ноде тяжело асинхронности контролировать, вроде для этого есть rxjs но я им не пользовался
Yaroslav
Ilya
Если в ноде то async await, если go то gorutine, но всеравно проритет сохранения за последним запросом, иными словами если 100 запросов единовременно на сохранение или апдейт одного поля, то результатом будет то, что выполнит я последним, в ноде тяжело асинхронности контролировать, вроде для этого есть rxjs но я им не пользовался
Я не про то, как асинхронно запросы слать, я про то, как защитить документ от состояния гонки при запросе на апдейт из нескольких реплик
Ilya
То есть чтобы только один запрос вернул ок
Ilya
А остальные - ошибку
Ilya
Только их нет в монге
Yaroslav
Dmitriy
есть, с 4.0.2 если я ничего не путаю