Информация об изменениях

Сообщение Re[4]: Eventual consistency от 07.07.2018 19:06

Изменено 07.07.2018 19:08 Slicer [Mirkwood]

Re[4]: Eventual consistency
Здравствуйте, takTak, Вы писали:

T>если у тебя SPA, то там сам можешь симулировать на клиенте, что всё уже произошло, что усложняет клиента, конечно (в случае ошибки , однако, надо будет таки сказать: "оопс, произошла ошибка и т.д. и убрать данные с клиента")


Ну я пытался объяснить, в чем проблема с симуляцией. Как минимум в определении того, где добавленное располагается относительно всего остального. Другие-то вещи (прямой доступ по id, или даже поиск по каким-то критериям) в большей или меньшей степени можно подделать.
Хотя вообще-то да, я ранее написал неверно: зная критерий сортировки, можно, уже получив N-ную страницу с сервера, понять, должен ли внутрь нее попадать новый документ. Может и вариант. Но опять-таки, вот мы прочитали список с сервера, наш документ должен идти третьим на этой странице, а его нет. Это может означать что наш документ еще не попал на этот шард. Но это с тем же успехом может означать что его кто-то уже успел удалить =) И в этом случае ясное дело не нужно вставлять в список нашу копию.
И еще, кстати, вставка внутрь принятого от сервера списка означает, что нужно из него тогда последнюю или первую строку выкинуть; а так как выкинутая появляется только на этой странице и никаких других, то получается юзер никогда ее не увидит, как бы он не переключал страницы, до тех пор пока наша фиктивная запись не придет ему честно с сервера. Хотя тут тоже можно побороться — запрашивать с сервера сразу по 2 страницы вместо одной, и вырезать из них нужный кусок в зависимости от того где находится фиктивная запись относительно полученных. Так что это вроде бы решаемо.

Slicer
Re[4]: Eventual consistency
Здравствуйте, takTak, Вы писали:

T>если у тебя SPA, то там сам можешь симулировать на клиенте, что всё уже произошло, что усложняет клиента, конечно (в случае ошибки , однако, надо будет таки сказать: "оопс, произошла ошибка и т.д. и убрать данные с клиента")


Ну я пытался объяснить, в чем проблема с симуляцией. Как минимум в определении того, где добавленное располагается относительно всего остального. Другие-то вещи (прямой доступ по id, или даже поиск по каким-то критериям) в большей или меньшей степени можно подделать.
Хотя вообще-то да, я ранее написал неверно: зная критерий сортировки, можно, уже получив N-ную страницу с сервера, понять, должен ли внутрь нее попадать новый документ. Может и вариант. Но опять-таки, вот мы прочитали список с сервера, наш документ должен идти третьим на этой странице, а его нет. Это может означать что наш документ еще не попал на этот шард. Но это с тем же успехом может означать что его кто-то уже успел удалить =) И в этом случае ясное дело не нужно вставлять в список нашу копию. Проблема.

И еще, кстати, вставка внутрь принятого от сервера списка означает, что нужно из него тогда последнюю или первую строку выкинуть; а так как выкинутая появляется только на этой странице и никаких других, то получается юзер никогда ее не увидит, как бы он ни переключал страницы, до тех пор пока наша фиктивная запись не придет ему честно с сервера. Хотя тут тоже можно побороться — запрашивать с сервера сразу по 2 страницы вместо одной, и вырезать из них нужный кусок в зависимости от того где находится фиктивная запись относительно полученных. Так что это вроде бы решаемо.

Slicer