|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev ... 3. В это время пользователь может таки успеть дойти до тех мест где эти данные требуются. Если такое произошло, то показываем пользователю спиннер, мол, "мы запрашиваем данные, жди". Как только данные пришли - спинер прячем, показываем то ради чего он сюда пришел. Мне кажется, что если показывать "мы запрашиваем данные, жди", то и действительно в этот момент и выполнять сам запрос данных. Т.к. можно получить вменяемую ошибку от стороннего сервиса, показать ее пользователю и уже с этой вменяемой ошибкой он обратиться в техподдержку. Не нужно будет раскапывать логи, пытаться по метки времени находить ошибки и так далее и тому подобное. Мало того, возможно и сразу отправить в тех. поддержку стороннего сервиса, т.е. уменьшить работу своих коллег. А возможно ошибка от стороннего сервиса вообще будет звучать так "вы запретили доступ к своим персональным данным, поэтому они не предоставлены" - т.ч. возможно, даже сам пользователь эту ошибку и сможет устранить. Разумеется, откуда приходят данные мы не знаем, но с учетом "долгое время" можно предположить что это или сторонняя организация или вообще какая-то шина, типа СМЭВ (система межведомственного взаимодействия) или прочие личные кабинеты, контактики, линкедиды. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 09:36 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Что мне не понятно, откуда тут взялись проблемы с мани-то-мани. Если данные из разных источников, скорее всего они разнородные. Т.ч. необходимость обрабатывать их одним куском, для меня кажется сомнительной. Ну и по времени операций, конфликта не видно: 1. Модуль авторизации - авторизует и записывает заголовок 2. Модуль(и) кэширования - добавляют требуемые в данные момент времени куски информации из соответствующих сторонних сервисов, возможно добавляя ID заголовка-сессии, которой эти данные потребовались При чем тут мани-то-мани, нифига не понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 09:38 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар надеюсь смог объяснить суть. Описание юзкйса не начинается "сделаем в одном потоке". )))) Юзкейс описыает ДЕЙСТВИЯ ПОЛЬЗОВАТЕЛЯ. НАПРИМЕР 1.юзверь ввел sql.ru 1.1 не зарегестрирован 1.1.1 вводит инфо в форму регистрации. .... ?? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 09:58 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Если юзкейс выше верный, то мы получаем два потока. Основной и фоновый для юзверя. Основной это минимум данных (форма регистрации) Фоновым можно назвать что угодно в вашей системе. ИТОГО - В ЧЕМ ПРОБЛЕМА? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 10:05 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev Stanislav Bashkyrtsev ... 3. В это время пользователь может таки успеть дойти до тех мест где эти данные требуются. Если такое произошло, то показываем пользователю спиннер, мол, "мы запрашиваем данные, жди". Как только данные пришли - спинер прячем, показываем то ради чего он сюда пришел. Мне кажется, что если показывать "мы запрашиваем данные, жди", то и действительно в этот момент и выполнять сам запрос данных. Т.к. можно получить вменяемую ошибку от стороннего сервиса, показать ее пользователю и уже с этой вменяемой ошибкой он обратиться в техподдержку. Не нужно будет раскапывать логи, пытаться по метки времени находить ошибки и так далее и тому подобное. Мало того, возможно и сразу отправить в тех. поддержку стороннего сервиса, т.е. уменьшить работу своих коллег. А возможно ошибка от стороннего сервиса вообще будет звучать так "вы запретили доступ к своим персональным данным, поэтому они не предоставлены" - т.ч. возможно, даже сам пользователь эту ошибку и сможет устранить. И если встает вопрос про ошибки, то их прийдется записывать прям в БД чтоб потом показать пользователю когда он дойдет до той страницы. Ну или асинхронность можно сделать со стороны UI (фоновый AJAX запрос на получение этих данных), в случае SPA мы можем показать ошибку как только она возникла, даже находясь на другой "странице". Тоже рабочий вариант в некоторых ситуациях. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 10:11 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Не очень понял описываемое Вами. Думаю в целом мы об одном и том же, просто в разной терминологии ))) Да, делать можно по разному. Мне просто не очень понятен подход "при логине - подтянем данные". Мне понятен подход кэширования - данные из первоисточника получаются медленно, поэтому будем их кэшировать. Вариант cache - универсальный. Первый вариант - заклепотный велосипед. Завтра выяснится, что данные в сторонней системе могут меняться после логина и что? для обновления "баланса по счету" после онлайн платежа обязательно перелогинтесь? Заклепка. Ожидать, что к моменту операции все данные есть и/или есть вменяемая ошибка, мне кажется значительно более трудоемкий в программирование и тестирование. Восприятие процесса как cache и возможный (опциональным) прогрев кэша при логине - логичнее, соответственно проще кодируется, проще тестируется. По крайне мере для меня. IMHO ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 13:12 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
В данном топике - плохое ТЗ. Или недостаточно проработанное. Непонятно является ли обязательным наличие в объекте пользователя опциональных данных которые подтягиваются из сторонних систем. Кроме того автор всех запутал вводя какие-то книги и прочее. Тут в задаче нет технической проблемы вообще. Callable/Future. Retry-logic если не получили результат. Тут есть проблема недостаточной ясности что делать в тех и других ситуациях. Что делать если внешний сервис не ответил через час? Что делать если он в течение дня не ответил? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 13:26 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
mayton, +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 14:41 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
mayton, согласен на счет книг и тегов и изза этого привел более реальный пример кстати структуру бд менял... (на картинке можно посмотреть) тут самым важным является сервис по получении бирметрических данных это у меня паспорт и биометрические_данные а почти всех остальных таблиц можно в разных потоках таким образом юзверь ждет только прихода данных из главного источника для заполнения биометрических данных а другие таблицы асинхронно заполняются а вот если по какой либо причине кто то из них откажет то сбрасывается исключение и записи не будет, а при входе в систему можно будет ещё раз запросить если нет данных в других таблицах, в том числе адрес и пока для адреса таким сделал метод Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 16:07 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 16:45 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар, Я понял что ты читаешь только последний пост. Остальные нет. - биометрические данные обязательны а остальные нет? Тогда причем райзе на необязательные? Он же их НЕ ЖДЕТ! ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 17:51 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Если "записи не будет" относится к доп данным, то фиг с ними. Это не обязательные данные. Тогда в чем вопрос то. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 17:54 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар, getAddressFromRemoteServiceAndSaveData это не обязательные данные для входа? Тогда почему не повесить их на JOB/шедулер? ГОСУСЛУГИ смотрели? Там запрос в ГАИ на оплату штрафа. И юзверь может кроме шедулера самого сайта раз в сутки инициировать проверку кнопкой немедленно. Всё работает и все довольны. Работает AJAX и никакой асинхронности. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 18:01 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар, Ты AJAX из коробки заменил кучей кода и головной болью админа сервера и девочек техподдержки ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 18:03 |
|
|
start [/forum/topic.php?fid=59&gotonew=1&tid=2120353]: |
0ms |
get settings: |
17ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
56ms |
get topic data: |
6ms |
get first new msg: |
3ms |
get forum data: |
1ms |
get page messages: |
276ms |
get tp. blocked users: |
1ms |
others: | 291ms |
total: | 658ms |
0 / 0 |