yopp
Со всеми необходимыми условиями
D
@dd_bb можно в личку ?
Alex
по возможности не создавайте пользователей за пределами базы по-умолчанию
Не очень понял , если я хочу создать пользователя для конкретно базы , то его создать в админ базе ?
yopp
yopp
authenticationDatabase это не база к которой применяются права, а база источник самих прав
yopp
Это просто отвратительная часть монги
D
Не очень понял , если я хочу создать пользователя для конкретно базы , то его создать в админ базе ?
могу скриптом на js поделиться для этого. стандартный кейс для CI/CD
yopp
Сюда, это может помочь другим
D
ок
Speedy
утро в хату
Speedy
в монго компассе, есть ауто рефреш?
Speedy
потому что вручную каждый раз мышью через два экрана ползти туда обратно и кликать рефреш уже давление поднимается
D
@dd_bb
есть колекция сhunks
в ней храняться документы у которых есть поля user, start, finish.
документ описывает кусок данных за конкретный промежуток времени start-finish.
нужно обеспечить проверку которая будет гарантировать, что все добавляемые chunk не пересекаются по времени
например.
в колекции уже есть следующие чанки.
user, start, finish:
1 0 10
1 20 30
1 40 50
добавление
1 11 13 - ok
1 5 8 - err
1 5 14 - err
1 14 25 - err
перед добавление chunk в колекцию я делаю find на проверку нет ли пересечения с уже существующими чанками.
запрос на проверку:
const res = await chunks.find({
query: {
user,
$or: [
{ start: { $lte: dataIn.start }, finish: { $gte: dataIn.start } },
{ start: { $lte: dataIn.finish }, finish: { $gte: dataIn.finish } },
],
},
});
когда на backend прилетают два взаимоисключающих запроса например.
1 11 16
1 13 18
из-за ассинхронности они оба попадают в колекцию, а должен только 1 из них. это происходит потому, что.
find1, insert1 , find2, insert2.
выполняются как find1, find2, insert1, insert2.
D
хм, и как мне транзакции помогут ?
Nick
@dd_bb
есть колекция сhunks
в ней храняться документы у которых есть поля user, start, finish.
документ описывает кусок данных за конкретный промежуток времени start-finish.
нужно обеспечить проверку которая будет гарантировать, что все добавляемые chunk не пересекаются по времени
например.
в колекции уже есть следующие чанки.
user, start, finish:
1 0 10
1 20 30
1 40 50
добавление
1 11 13 - ok
1 5 8 - err
1 5 14 - err
1 14 25 - err
перед добавление chunk в колекцию я делаю find на проверку нет ли пересечения с уже существующими чанками.
запрос на проверку:
const res = await chunks.find({
query: {
user,
$or: [
{ start: { $lte: dataIn.start }, finish: { $gte: dataIn.start } },
{ start: { $lte: dataIn.finish }, finish: { $gte: dataIn.finish } },
],
},
});
когда на backend прилетают два взаимоисключающих запроса например.
1 11 16
1 13 18
из-за ассинхронности они оба попадают в колекцию, а должен только 1 из них. это происходит потому, что.
find1, insert1 , find2, insert2.
выполняются как find1, find2, insert1, insert2.
Но есть другой вариант, вы рядом с старт и енд кладете массив с одетльными часами, если у вас кратно часам, и настраиваете уникальный индекс, тогда второй инсерт сломается при вставке
Nick
хм, и как мне транзакции помогут ?
У вас find либо отработает на старых либо уже на новых данных
D
Но есть другой вариант, вы рядом с старт и енд кладете массив с одетльными часами, если у вас кратно часам, и настраиваете уникальный индекс, тогда второй инсерт сломается при вставке
прикольная идея, но у меня не кратно часам. кратно ms
D
У вас find либо отработает на старых либо уже на новых данных
сори все равно не понял
у меня же проблема в том, что второй find делаеться то дого как первый insert отработал. мне нужно этого избежать . мне транзакции не помогут.
или я не понимаю
Nick
Чет я начинаю сомневаться, но вроде как раз помогут
D
тогда расскажите как ))
D
моя проблема в том что мне нужно заблокировать колекцию на чтание для всех потоков
пока мой find1 + insert1 не отработает
D
@yatoba
транзакции блокируют колекцию на чтение (exclusive) только при операции insert, а мне нужно на find + insert
D
@yatoba другими словами мне нужна класическая Write Locks на колекцию
Nick
Да касяк
yopp
Так как транзакция отменяется целиком, то в вашем случае поведение будет как вы хотите
yopp
Если будет большое число абортов транзакций, можно будет оптимизировать
Апач
Хеллоу, кто-нибуть пытался завести исполнение тайпскрипта в монге?
так которые mongo shell scripts. Бестиповаый жс уже потихоньку начал задалбывать
yopp
yopp
Компилируйте в js
Апач
А вот с этого места можно по подробнее?
yopp
Не стоит опираться на какие-то специфические фичи js-движка используемого в монге, так нет спецификации того, что этот движок должен поддерживать
Davа
D
Самый простой вариант, это в транзакции изменять ещё один документ, который будет выступать как мьютекс
можете чуть подробнее расписать подход?
D
yopp
можете чуть подробнее расписать подход?
Если две транзакции имеют конфликтующие изменения, то применятся только одна. Вторая не применяется. Смысл в том, чтоб создать какой-то документ который будет вызвать конфликт. Например сделать счётчик числа обновлений, который читается и потом записывается. Две транзакции будут конфликтовать и одна проиграет гонку
D
а счетчик обновлять не через $inc а через $set ? или пофиг ?
D
@dd_bb ^
D
@dd_bb, а этот счетчик будет в каждом документе
и я должен обновлять счетчики во всех документах которые вернет find?
D
@dd_bb
так стоп, так у меня же проблема, что find ничего не вернет потому что к моменту выполнения find1 и find2, insert1 и insert2 еще не исполнились.
походу не сработает ваша идея. черт . прикольный финт .
D
@dd_bb ваш подход это подобие уникального индекса. но в моем случаи не прокатит.
или я туплю, поясните плиз
yopp
yopp
Это аналог обычного мьютекса. Это базовый примитив синхронизации
D
@dd_bb
а.. вы предлагаете через этот мьютекс делать блокировку любых операций в колекции из всех транзакций ? аля все операции в колекции последовательными будут
yopp
Да
D
жесть.. в смысле прикольно )))
я подумаю спасибо
не, точно жесть :D
yopp
Добавьте сразу мониторинг числа абортов транзакций и когда число будет в десятках в секунду, плюс будет сильно влиять на задержки, то можно уюте подумать об оптимизации
yopp
D
а как это будет работать?
не как write lock в реляционках
я имеею ввиду, что остальные транзакции будут ждать пока снимиться лок.
или в каждом случаи это будет abort ?
D
т.е. не будет почти никаких локов, просто в момент коммита, монго будет видеть что версия документа поменялась и будет откатывать транзакцию которая стартанула сдругой версией ?
D
да уж. мисьё знает толк в извращениях :D
спасибо.
PS
нормально вы так плаваете во всем этом
впечатляет
Апач
ещё вопрос, можно ли как-то сконфигурировать лимит на 60 с в транзакции и на 1000 доков?
Апач
Подозреваю что нет
Апач
и если нет, то как пропатчить сорсы?
yopp
ещё вопрос, можно ли как-то сконфигурировать лимит на 60 с в транзакции и на 1000 доков?
Лимит на какую операцию?
Dmitriy
Коллеги, кто сталкивался с такой задачей:
Мне приходит обьект
{a: {b: {c: 1}}}
И мне нужно засетить изменения именно этого значения у документа (Не перезаписывать весь обьект а засетить именно этот обьект.
Это делается через
["a.b.c"] = 1
Может есть утилита для JS которая преобразует проперти обьекта в такие пути?
Oleg
А как в mongodb хранить большие целые числа? NumberLong не больше, чем 22, а как больше? Например, wei из Ethereum?
Oleg
Oleg
yopp
Nick
The end.
https://github.com/backmeupplz/randymbot
Nick
читайте сообщение ошибки
Nick
видимо нет, выедите в консоль или дебагом првоерьте
Alex
Всем привет!
Кто сталкивался с тем, что если запустить 2 докера (client + api + mongo) то будет конфликт, что порт 27017 уже занят, а если порты перенаправить 27018:27017, то конфликт пропадает, но происходят ошибки с данными (как будто данные берутся из двух баз поочередно, как-то некорректно). Кто знает куда смотреть и что делать?
Roman Khonichev
попробуйте название запущенных контейнеров поправить... если они одинаковые, то поочередно и будет браться... аля встроенный roundrobin