Проблема. Не везде 4G. Моб. клиент может находиться в зоне нестабильного приема 3G, а то и GPRS, в роуминге. По той же причине невозможна интенсивная работа с приложением в онлайн режиме.
Включить приложение в зоне нестабильного приема, получить пару-тройку коротких вчерашних-позавчерашних обновлений с БД чтобы как можно быстрее выйти в готовность к работе - далее интенсивная работа с данными оффлайн, и в итоге - короткий ответ серверу - основной режим работы.
При подключении клиент запрашивает обновление со временем последнего обновления и локальным временем (видел неправильно настроенные часы миллион раз)
Пока к такой схеме и склоняюсь, но поступаю проще - хранение номера версии данных. Клиент знает какая последняя версия у него, и делает запрос с номером свой версии. Сервер в ответ дает данные с версиями выше.
Для работы в обе стороны нужен полный лог операций и система разрешения конфликтов
Благо такое не требуется. Пока. Но если существуют такие решения - было бы неплохо применить и их с учетом на будущее.
Для обычных баз данных в режиме совместной работы настраивайте мастер-мастер репликацию с транзакциями
Из-за разнородности хранения данных на сервере и клиенте такое неприменимо, к сожалению.
Для мобильных приложений используйте режим тонкого клиента.
На мобильном устройстве данные хранятся в специфическом формате. Для простоты примем что хранится некая структура в json собранная из актуальных данных.
Так вот - родные механизмы репликации mysql/postgresql позволяют настаивать репликацию с некой внешней структурой json c протоколами на базе json а лучше protobuf?
Если да - ткните в примеры успешной реализации. Я к примеру такое не нашел, и не думаю что репликация мне поможет.
Иван, а где можно глянуть подобную реализацию? Если на входе мне просто нужно указать номера версий, а получить в итоге - что удалить/что добавить/а что изменить в таблице данных для синхронизации.
> Записывайте не версию, а время изменения состояния записи.
А чем это принципиально отличается от записи версии - если я ее инкрементирую после внесения данных. Временная метка - просто частный случай версии, насколько я понимаю )
Евгений Самсонов, > Клиенту нужно выполнить все изменения последовательно
Как раз этого нужно избежать.
Допустим на версии 2 добавили миллион записей
на версии 3 этот миллион записей удалили, но добавили 2 новых записи
Клиенту должно прилететь в итоге что нужно добавить 2 новых записи, а не закачивать миллион записей, а затем в следующем изменении их удалять чтобы оставить 2 записи. Нужно как раз свести к минимуму количество информации передаваемой от сервера - этот ресурс как раз необходимо сэкономить.
> С чем связано это? И как это решить?
По двум строкам кода тяжело понять. Приведите более развернуто - каким образом подключаетесь к БД, какова структура таблицы, и прочую информацию которая может быть полезной в решении вопроса.
> все библиотеки которые я нахожу, заточены на utf и жутко криво его парсят
С Latex дела не имел - но к примеру пакетное преобразование файлов в utf-8 тем же
iconv -f cp1251 -t utf8 не пробовали?
vovka_losira, вообще такое впечатление что вы пишете кодировке windows-1251 или вроде того
Попробуйте преобразовать строку в utf-8 перед записью в базу
nrgian, фейк - не фейк - какая разница. Если пользователь-параноик в результате сошлется на вас правоохранительным органам да хоть под надуманным поводом - что вы его данные врагам сливаете к примеру... У вас могут быть вполне реальные проблемы в связи с хранением персональных данных пользователей. Впрочем - вам решать. Чего сообщество тогда спрашивать )
Noir, предварительно установите нужные модули в консоли (выйдя из интерпретатора python)
pip install lxml requests
а лучше почитайте про virtualenv и используйте его
Проблема. Не везде 4G. Моб. клиент может находиться в зоне нестабильного приема 3G, а то и GPRS, в роуминге. По той же причине невозможна интенсивная работа с приложением в онлайн режиме.
Включить приложение в зоне нестабильного приема, получить пару-тройку коротких вчерашних-позавчерашних обновлений с БД чтобы как можно быстрее выйти в готовность к работе - далее интенсивная работа с данными оффлайн, и в итоге - короткий ответ серверу - основной режим работы.
Пока к такой схеме и склоняюсь, но поступаю проще - хранение номера версии данных. Клиент знает какая последняя версия у него, и делает запрос с номером свой версии. Сервер в ответ дает данные с версиями выше.
Благо такое не требуется. Пока. Но если существуют такие решения - было бы неплохо применить и их с учетом на будущее.
Из-за разнородности хранения данных на сервере и клиенте такое неприменимо, к сожалению.
Тоже не подойдет из-за проблем описанных выше.