LINUX.ORG.RU

отложенная синхронизация записей (один сервер - много клиентов)


0

3

Сферический пример. Допустим, есть телефонный справочник: набор записей (айди, имя, телефон)

Вся эта байда хранится на сервачке и отображается вебмордой.

Теперь, у нас есть два телефона, один работающий под андроидом, второй - под огрызком яблока, на каждом из них есть клиент, редактирующий тот же самый список

Теперь Вася и Петя взялись редактировать несчастный справочник с разных телефонов. При этом возникают конфликты, аналогичные конфликтам в VCS при редактировании одного ресурса.

С одной стороны, при нажатии кнопочки «синхронизация» можно сразу сливать всю базу с телефона Васи, но тогда все изменения Пети (коих в случае менее сферического примера будет прилично) будут потеряны

С другой стороны, можно все изменения представлять в виде ченжсетов, где-то хранить их в телефоне, и отправлять на синхронизацию пачку ченжсетов. На сервере в веб-морде отображается shallow copy, но также где-то хранится полная история, и если ченжсеты не двигают историю вперед, а вклиниваются посередке, то происходит полная перестройка истории. На телефоне хранится shallow copy.

Перестройка истории - дело долгое, не приведет ли это к слайдшоу в реальных ситуациях? (объемы - например, количество заказов водки для предприятия, торгующего водкой. Куча агентов ходят со смартами, в которых «список заказов», а синхронизуют их когда появится инет)

Стоит ли разрешать конфликты в полностью актоматическом режиме? Если да, то какие? Пользователь - не программист. Что с ним произойдет от сообщения вроде: «вы пытаетесь обновить телефон, который был уже удален. Восстановить телефон?», сорвет крышу?

Главный вопрос в том, что, мб, кто-то уже все придумал, и достаточно применить хорошую практику. Где посмотреть? Хотя бы на примере сферической телефонной книжки?

(Заодним, сей тупак продолжать спрашивать здесь, или сразу в толксы?)

★★★★☆

Когда пользователь начинает редактировать запись она блокируется для редактирования/удаления.

pi11 ★★★★★
()
Ответ на: комментарий от pi11

понимешь, у телефонов бОльшую часть времени нету инета.

продолжая пример, человек уезжает в отпуск и на рабочем ПК редактирует книжку, забыв включить автосинхронизацию

потом в отпуске (в глухом лесу, где водятся кикиморы и голые стриптизерши - есть чем заняться, кроме как установкой телефонных вышек) редактирует пару записей со смарта

потом приезжает из отпуска домой, а там инет за неуплату отключили. И с домашнего смарта что-то редактирует, опять же не коммитя данные (нету инета)

потом едет на работу и коммитит там с ПК

потом долго бродит по офису, находит незапароленный вайфай и сливает данные с «походного смарта»

потом возвращается домой, плотит за интернеты и коммитит данные с домашнего смарта

и допустим там будут конфликты типа «отредактировать уже удаленное» и «удалить то, с чем в будущем сделают 100500 операций»

какой-то такой кейз

stevejobs ★★★★☆
() автор топика

тебе не кажется, что проблема синхронизации телефонной книжки (аналогично VCS) и заказов на водку (здесь что собрался синхронизировать - дубликаты заказов и/или соответствие объёмов продаж возможностям?) сликшом разные задачи?

mashina ★★★★★
()
Ответ на: комментарий от mashina

Давай в рамках этой задачи ограничимся абстрактными записями, с возможностью получить детальную структуру, проверить ссылочную целостность, итп. Телефонная книжка, to-do list, что-нибудь такое. Завод с водкой я запоздало присобачил для того, чтобы показать, что записи могут быть связаны (т.е. элементом записи может быть ссылка на другую запись, в смысле аггрегации или зависимости по времени, как в случае заказов)

stevejobs ★★★★☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.