N
Всем привет!
Есть ли для связи node + mongoDB полноценная ORM? А не ODM как монгус?
Есть ли для связи node + mongoDB полноценная ORM? А не ODM как монгус?
а чем монгус не орм?
Size: a a a
2021 January 21
M
представь что идет запрос первый и второй, и каким то образом мы сохранили количество в перемонной а дальше пустили асинхронно и там была количество 3000, и придет второй запрос когда первый не успел и он увидит что там тоже 3000 и тоже сделает отписку но первый не успевает, в конечном итоге оба берут и делают set 2999
M
Всем привет ребята, столкнулся с ошибкой:
function s(){for (let t=1;t<i1l+1;t++) {
^
ReferenceError: Cannot access 'i1l' before initialization
помогите починить...
function s(){for (let t=1;t<i1l+1;t++) {
^
ReferenceError: Cannot access 'i1l' before initialization
помогите починить...
M
ситуация редкая но если есть хорошое решение буду рад знать решение
N
Mozart
представь что идет запрос первый и второй, и каким то образом мы сохранили количество в перемонной а дальше пустили асинхронно и там была количество 3000, и придет второй запрос когда первый не успел и он увидит что там тоже 3000 и тоже сделает отписку но первый не успевает, в конечном итоге оба берут и делают set 2999
транзакции обычно решают такое, но эксперты по sql и хайлоуду здесь наверно лучше подскажут
ak
а чем монгус не орм?
ODM по определению..
M
транзакции обычно решают такое, но эксперты по sql и хайлоуду здесь наверно лучше подскажут
кстати транзакции уже работают по очереди верно ?
ak
а чем монгус не орм?
по сути обертка над запросами
M
не будет того что две транзакции паралельно верно ?
ЕВ
Mozart
я сделала систему подписок, one To many (User - Follow) так вот есть запрос который должен искать юзера с наибольшым количество подписок, так вот как сделать правильно составить запрос, я думаю создвть свойство внутри Entiy но боюсь что из за болшьго количество запросов, запросы пойдут в хаусном порядке и в результате будут не верные данные
я не знаю как в orm но в постгресе я бы сделал так:
1) вынес подписки в отдельную таблицу и сохранял бы их там.
2) у подписки внешний ключ USER_ID
3) при запросе считал бы все подписки по USER_ID
1) вынес подписки в отдельную таблицу и сохранял бы их там.
2) у подписки внешний ключ USER_ID
3) при запросе считал бы все подписки по USER_ID
N
ODM по определению..
не так вопрос задал, что нужно от орм для монги?
M
я не знаю как в orm но в постгресе я бы сделал так:
1) вынес подписки в отдельную таблицу и сохранял бы их там.
2) у подписки внешний ключ USER_ID
3) при запросе считал бы все подписки по USER_ID
1) вынес подписки в отдельную таблицу и сохранял бы их там.
2) у подписки внешний ключ USER_ID
3) при запросе считал бы все подписки по USER_ID
не ну это уже сделано, тут вопрос другой как сортировать юзеров по количеству их подписчиков
N
я не знаю как в orm но в постгресе я бы сделал так:
1) вынес подписки в отдельную таблицу и сохранял бы их там.
2) у подписки внешний ключ USER_ID
3) при запросе считал бы все подписки по USER_ID
1) вынес подписки в отдельную таблицу и сохранял бы их там.
2) у подписки внешний ключ USER_ID
3) при запросе считал бы все подписки по USER_ID
если нужно вывести в табличке юзеров и возле каждого количество его подписок и его подписчиков, а таких юзеров тысячи, разве это будет эффективно?
N
разве что читать все подписки и на уровне приложения раскидывать их по юзерам
ЕВ
Mozart
не ну это уже сделано, тут вопрос другой как сортировать юзеров по количеству их подписчиков
в постреге group by count
M
в постреге group by count
оо круто можно узнать по подрообнее, я щас про гуглю просто сомнение есть какие то, вдруг что то не поняли (ну скорее всего я )
ЕВ
Mozart
оо круто можно узнать по подрообнее, я щас про гуглю просто сомнение есть какие то, вдруг что то не поняли (ну скорее всего я )
если я не ошибаюсь
select count(id) from subscriptions where user_id = 1 group by count descПА
Mozart
представь что идет запрос первый и второй, и каким то образом мы сохранили количество в перемонной а дальше пустили асинхронно и там была количество 3000, и придет второй запрос когда первый не успел и он увидит что там тоже 3000 и тоже сделает отписку но первый не успевает, в конечном итоге оба берут и делают set 2999
тут нужно версионирование применять при обнволениях или атомарные операции со стороны монги, контекста кейса нужнго больше
M
тут нужно версионирование применять при обнволениях или атомарные операции со стороны монги, контекста кейса нужнго больше
тут postgres sql
N
кстати, вот в хорошей архитектуре, на каком уровне долнжы быть реализованы sql транзакции?