p
Б... в асинке и еще с тредами е...
Можно не юзать асинк
Size: a a a
2020 January 07
Е
тут же скидывали ссылку про то, что async orm не всегда оправданы, что ты вылез-то
Я иду до конца
А
это характеристика отношения, а не самой модели
в случае с json у тебя это будет характеристикой модели
в случае с json у тебя это будет характеристикой модели
Просто если хранить в одной из колонок модели JSON, где ключ-айди продукта, значение-количество, то все нормально выходит. Я когда данные отдаю на фронт, только айдишники возвращаю
E
Просто если хранить в одной из колонок модели JSON, где ключ-айди продукта, значение-количество, то все нормально выходит. Я когда данные отдаю на фронт, только айдишники возвращаю
ты согласен с тем, что количество покупок это характеристика именно отношения между моделями?
ЮЧ
ты согласен с тем, что количество покупок это характеристика именно отношения между моделями?
Явно не стоит поля
А
ты согласен с тем, что количество покупок это характеристика именно отношения между моделями?
Тут скорее не количество покупок, а сколько продуктов за раз. Т.е. модель у меня Invoice(чек), и за инвойс можно купить несколько продуктов одного типа(quantity)
G
Хранить список покупок каждого пользователя через связь, при надобности подсчитать
E
Хранить список покупок каждого пользователя через связь, при надобности подсчитать
это лучше идея, таки-да
А
Хранить список покупок каждого пользователя через связь, при надобности подсчитать
Если ты про список инвойсов, то я так уже делаю
А
В общем понял, хоть и теперь можно хранить хоть массивы, хоть json в базе в колонке, все равно надо делать олдскульными many-to-many) ок)
c
а если в State записывать данные юзера, а потом их все в бд?
t
а если в State записывать данные юзера, а потом их все в бд?
никто не запрещает
c
ну ето норм тема вообще?
c
я вчера вот подумал, что можно так сделать
Е
Хранить список покупок каждого пользователя через связь, при надобности подсчитать
Типо юзер<- корзина ?
G
ну ето норм тема вообще?
А зачем, и так же записывается в нужное тебе хранилище
ЮЧ
а если в State записывать данные юзера, а потом их все в бд?
Ну Стейт для того и нужен, чтобы хранить промежуточные данные
G
Ну Стейт для того и нужен, чтобы хранить промежуточные данные
Ну если такой кейс, когда в конце сессии удаляются из стейта
c
А зачем, и так же записывается в нужное тебе хранилище
ну они потеряются потом, если в памяти допустим держать
а я хотел их просто собрать, а когда юзер перехоилдт к оплате, то уже записать все в бд и дать ему 10 минут резерва товара
а я хотел их просто собрать, а когда юзер перехоилдт к оплате, то уже записать все в бд и дать ему 10 минут резерва товара
G
ну они потеряются потом, если в памяти допустим держать
а я хотел их просто собрать, а когда юзер перехоилдт к оплате, то уже записать все в бд и дать ему 10 минут резерва товара
а я хотел их просто собрать, а когда юзер перехоилдт к оплате, то уже записать все в бд и дать ему 10 минут резерва товара
А ты не записывай в памяти