Можно ли в Android ContentProvider поддерживать функцию add-swap-drop для таблиц БД?

Question

Меня просят предоставить схему двойного кэша для синхронизации облачной БД с БД устройства.Требуется создать набор таблиц, а затем в определенный момент времени произойдет синхронизация с зеркалом того же набора таблиц.Когда это будет сделано, ожидается, что ContentProvider поменяет один набор на другой, не обращая на это внимания приложения.

Возможно ли это?

Можно ли безопасно добавлять таблицы-подкачки-отбрасывания?Можно ли безопасно добавить-поменять-отбросить несколько таблиц - некоторые действия могут отображать объединения?

Комментарии и идеи приветствуются, но нельзя объединять синхронизацию существующих таблиц.

Меня беспокоит то, что могут быть невыполненные курсоры в Операциях или Сервисах, которые работают с набором таблиц, и нет способа гарантировать, что они закрыли курсор до того, как таблица, к которой он может получить доступ, будет отброшена.

Answer 1

Да, это возможно (даже если ваше требование к двум столам от вашего клиента звучит как очень уродливый хак.)

Ваш ContentProvider должен обслуживать курсор в ответ на определенный URI контента. Как этот URI отображается на таблицу в базе данных, полностью зависит от вас.

Так сделайте это: Создайте 2 таблицы «data1» и «data2» с идентичной схемой базы данных. Заполните data1 вашими данными, как обычно. Когда приложение запрашивает ваш URI, ответьте курсором, заполненным данными из data1.

Позже, заполните данные2. Когда приходит команда и пришло время переключать таблицы, вызовите notifyChange () с (одним) URI, который вы используете для этих данных. Все прослушивающие курсоры (ваши приложения отображения , использующие RegisterContentObserver (), не так ли?) Будут уведомлены об изменении данных в вашем URI. Когда они получат это уведомление, они повторно запросят. На этот раз ваш ContentProvider ответит данными из table2 вместо table1 ... Курсор не знает, из какой таблицы она заполнена, только из какого URI. Таким образом, для приложений, использующих данные, изменение полностью прозрачно (при условии, что две таблицы имеют одинаковую схему.)

Я замалчивал командование коммутатором и сохранял, какая таблица активна. Это, очевидно, своего рода приложение, специфичное для вас, но вы должны быть в состоянии найти хороший способ сохранить эту информацию уже.

Что касается таблиц JOINS ... Хитрость заключается в том, чтобы гарантировать, что логика выполнения самого JOIN происходит внутри ContentProvider, а не внутри приложения. Затем вы просто переключаете несколько наборов таблиц и выполняете JOIN из правильных наборов.

Наконец, что касается устаревших курсоров, курсор содержит копию данных таблицы, а не ссылку на саму таблицу. Поэтому, если таблица исчезнет, ​​данные Курсора в худшем случае будут устаревшими. Он не будет держать стол открытым или тому подобное. Курсор хранит обратную ссылку на URI контента, из которого он получен, а не на таблицу. Итак, опять же, когда он запрашивает, он будет работать так же, как и выше.