|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Здравствуйте, собственно сабж что делаю: сущность Tag Код: java 1. 2.
сущность Book Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
будет естественно работать вот так: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
и собственно вопрос если для каждого энтити разные удаленные источники как можно асинхронно получить и записать эти данные? знаю что транзакция и асинк вместе не будет работать и к тому же нельзя изменить объект асинхронно... в моем случае мне достаточна сохранить книгу и выдавать инфу, пусть теги асинхронно добавляются... З.Ы. возможно книги и теги не совсем удачный пример, но с юзером и адресом будет правильнее наверно, но суть не меняется )... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 16:26 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Ты хочешь сохранить книгу в одном потоке (и в одной транзакции), а тэги сохранить в другом потоке (и другой транзакции)? Ну особых проблем не вижу, только книгу нужно будет сначала закоммитить, иначе tx#2 не увидит ее. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 16:32 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал? если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 16:38 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар Stanislav Bashkyrtsev, в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал? если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом Делай синхронно. :-) Можно конечно покапать в сторону чего-нибудь реактивного/корутинного. Но это сложнее. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 17:10 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
mad_nazgul, да делал бы так, но для увеличения скорости делал асинхронным, или сделать наоборот т.е. сделать основным не книгу а тегов? или вообще из ассоциативной таблицы сделать ещё один сущность... ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 17:31 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар Stanislav Bashkyrtsev, в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал? если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом Музаффарили сделать наоборот т.е. сделать основным не книгу а тегов? или вообще из ассоциативной таблицы сделать ещё один сущность...Можно и так. PS: Я не видел еще подобных ситуаций, чтоб сохранение сущностей было такое медленное, чтоб нужно было в async выносить.. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 17:57 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
AFAIK кроме синхронности/ассинхронности, есть еще такая вещь, как колличество коммитов на единицу записываемых данных ))) т.ч. можно сделать все ассинхронным, но скорость будет на порядки (десятки-сотни) раз медленней, чем синхронно но в одной транзакции. А если в одной транзакции еще и массово писать (например команда COPY), то смысла в ассинхронности записи в БД вообще может не быть, т.к. один клиент вполне будет способен сервер и диск сервера загрузить по самое нехочу (даже при хорошем сервере и хорошем серверном диске, сотню мегобайт с клиента чисто данных... не каждый сервер выдержит). ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 18:44 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
отвечу на вопрос зачем синхронность вообще: дело в том что данные берутся из удаленных сервисов, и если они загружены то ответ приходит чуть дольше иногда доходит до минуты... и когда все в одном потоке то придется ждать условно 1+ минут чтоб данные пришли и записались в бд ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 20:04 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар, Очень странное ТЗ. - можно собирать коллекцию в оперативке ПОКА ВСЕ ДАННЫЕ НЕ ПРИДУТ - можно собирать во временной таблице в бд. Тебе как лучше?))) ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 22:27 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар, СУБД не мусорка чтобы писать туда что попало. Например одну руку от человека. Или один палец. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.09.2021, 22:29 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Музаффар, Очень странное ТЗ. - можно собирать коллекцию в оперативке ПОКА ВСЕ ДАННЫЕ НЕ ПРИДУТ - можно собирать во временной таблице в бд. Тебе как лучше?))) 1. Согласен но это не даст мне то что надо, т.к. время ожидания останется прежним. 2. Это что даст? - знаю что СУБД не мусорка но к чему это? У меня сбор данных происходит из разных источников следовательно время на это уходит по разному чтоб уменьшить это мне нужно как то параллелить обработку данных, т.е. в момент ввода названии книги из одного источника придёт инфо об этой книги и там же из другого источника теги по этой книги. При этом пользователь не должен ждать сбора данных по тегам и их записи в бд ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 05:15 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар, Тебе нужно делать так как учат в ВУЗАХ, ПЕРВЫЙ ЭТАП это создание модели и выделение сущностей. Если в твоей ИС "Б" сущность книга, то пол книги это промежуточный этап и ненужно полкниги писать в субд. Нужно складировать в сессию и собирать всю книгу. Если наборот, в твоей "Б" важны "источники книги" то сущность уже не книга а куски книги с меткой источника. ID_ИСТОЧНИКА NAME DATETIME >При этом пользователь не должен ждать сбора данных по тегам и их записи в бд ≠Он в любом случае не ждет. Запись в бд занимает милли и макро секунды. А ответ сервиса" А" занимает минуту. Юзверь ждет сервис А а не твой сервис Б. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 11:10 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар, Пора переходить к логам по времени и дать в топике цифры нагрузочных тестов. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 11:12 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
БД не запрещает асинхронность и мультипоточку. Но в БД есть констрейнты которые определяют целостность объектов. И было-бы лучше чтобы эти констрейнты были максимально строгими по отношению в записываемому объекту. В противном случае у нас в БД будет мусор. Тоесть какие-то огрызки книг тегов и непонятно где логический конец. Возможно имеет смысл просто накапливать в памяти модель сложного объекта и записывать его когда он будет полностью сформирован. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 13:28 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
mayton , если мы получаем неполные данные и могли бы их уже показать пользователю не заставляя его ждать еще минуту, то тут других вариантов то и нет. И мы БД должны подстроить под наши требования, а не под высокие (но не достижимые) идеалы. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 14:50 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД? Тем более что Музафар пишет что с некоторых сервисов данные приходистя ждать более минуты. Запишете в БД когда будет готов весь бизнес-объект. У вас же не возникает желания сохранять в базу формочку строка-за-строкой в той скорости как оператор из набирает. Верно? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 15:05 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
mayton Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 15:37 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Пускай автор скажет. Получается что мы тут сильно додумываем бизнес-сценарии. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 15:52 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Если речь про перформанс, подозреваю разговор идет о каком-то батч процессе или ETL. Мне даже кажется, что пару месяцев назад похожая тема уже всплывала. "Hibernate наше все" ( TM ) - т.ч. хождение по граблям может продолжатся долго. Наша песня хороша, начинай с начала. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 17:16 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev mayton Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД? Это чисто вопрос ТС ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 19:55 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар отвечу на вопрос зачем синхронность вообще: дело в том что данные берутся из удаленных сервисов, и если они загружены то ответ приходит чуть дольше иногда доходит до минуты... и когда все в одном потоке то придется ждать условно 1+ минут чтоб данные пришли и записались в бд ИМХО стоит посмотреть в сторону чего-то типа RxJava . Для того чтобы "собирать" сущность. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2021, 20:44 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, + ребят со всеми утверждениями согласен, вижу что разные мнения изза того что я не правильно задал вопрос походу... за это сорри в целом попробую конкретизировать задачу: есть таблицы/сущности: Юзер (где логин пароль и т.д.), Документ (где биометрические данные, фио, дата рождения и т.д.), адрес (ну и так понятно только тут как постоянный адрес так и временный) и другие таблицы. задача зарегистрировать пользователя в системе (входные данные: логин/пароль/табельный номер) система получив эти данные с помощью табельного номера идет по разным удаленным сервисам и собирает нужные инфа (для документа, и для адреса), как выше говорилось что удаленные серверы не всегда отвечают моментально. кстати чуть не забыл здесь самая главная сущность это документ, если есть документ то можем пойти и запросить из других источников и так кейс №1 сделаем в одном потоке: все круто все замечательно но есть одна проблема, время регистрации займет от 1.5 секунды до 1+минут (это изза того какой то сервис скажем адрес заставил ждать) и к тому же если это все происходит в одной транзакции возможен откат т.к. какой то удаленный сервис дал исключение... возможно? скорее да. кейс №2 попробовать параллелить сбор данных, получив входных данных идем по документу получив документ идем по другим удаленным сервисам только уже этих сервисов вызываем асинхронно тогда у нас сбор данных будет прозрачным отдельно от основного потока, таким образом мы будем ждать только одного сервиса (основного) для Документа... надеюсь смог объяснить суть. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 07:35 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Музаффар , я такие проблемы решал след образом: 1. Сохраняем небольшой кусок данных который позволяет пользователю хоть сколько-то работать в системе. Коммит. 2. Тригерим жобу которая смотрит в БД и для всех у кого данные не проставлены - запрашивает эти данные. Если делать иначе, то есть риск что что-то в сервисе сломается (ну или просто наш сервер кто-то перезагрузит) и данные никогда не попадут в БД. А нам нужен механизм который попробует еще, а значит лучше ориентироваться на БД. Такая жоба может не только по требованию запускаться, но и по шедулеру. Хотя при насильном запуске можно все-таки явно указать про какие записи речь, иначе жоба может начать слать запросы для пользователей в другом порядке, а значит наш последний пользователь прождет не минуту, а 5. 3. В это время пользователь может таки успеть дойти до тех мест где эти данные требуются. Если такое произошло, то показываем пользователю спиннер, мол, "мы запрашиваем данные, жди". Как только данные пришли - спинер прячем, показываем то ради чего он сюда пришел. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 07:51 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Тут вопрос лежит в бизнес плоскости а не в технической. На что готов пойти бизнес чтобы дать пользователю начать работать с системой до полного сбора информации. Если очень надо, то да - создание временной записи и асинхронная джоба со всеми сопутствующими(обработка ошибок, откат транзакции, замена временной записи на постоянную). Судя по тому что тс задаёт такие вопросы он явно не искушен, так что вряд-ли представляет гемор вносимый асинхронностью в данном кейсе... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 08:25 |
|
Асинхронное сохранение данных при связи ManyToMany
|
|||
---|---|---|---|
#18+
Гемора не вижу. Но не понимаю, если данные хранятся в другой системе, зачем их тащить в основную? 1. Данные необходимы для авторизации. Попаболь не понятна, пока данные не собраны, корректно авторизовать в системе мы не можем. Пусть ждет или "система недоступна по техническим причинам". 2. Если таблицы в основной система эта кэш и данные при логине подкачиваются для "прогрева кэша". Тогда опять таки, кэш должен работать как кэш. Данные есть и более-менее актуальны - возвращаем из кэша, данных нет - запрашиваем в медленном хранилище, помещаем в кэш, возвращаем. Прогрев кэша: асинхронно (скорее всего в Java), дергаем get'еры которые данные из кэша возвращают и на результат просто забиваем нано-болт. Подкачка и сохранение данных, задача модуля реализующего кэширование, а никак не модуля авторизации 3. Данные нужны чисто для логирования. НО, логирование это необходимая часть процесса авторизации, т.ч. смотри п.1. Будут разборки службы безопасности, а логи пустые, фэкап. IMHO & AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2021, 09:26 |
|
Асинхронное сохранение данных при связи 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?all=1&fid=59&tid=2120353]: |
0ms |
get settings: |
24ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
711ms |
get tp. blocked users: |
2ms |
others: | 399ms |
total: | 1209ms |
0 / 0 |