Ага
А ещё если задавать какие-то условия (например, LIKE в WHERE), он может выдать другой порядок, так как будет обрабатываться со всевозможными оптимизациями

А если удалить несколько записей, а потом ещё несколько вставить, ууууу…)

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

Ребят, привет! Может быть уже был у кого-то похожий опыт с оффлайн работой приложения.
Как можно сделать поддержку оффлайн работы приложения с архитектурной точки зрения? То есть, чтобы было не только кэширование данных с сервера, а можно было производить модификацию этих данных также как через обычные сетевые запросы, но сохранять это оффлайн. А в случае подключения к сети синхронизироваться с сервером.

Был следующий опыт.
1. В базе есть модель данных. Скажем "name, age"
2. пользователь меняет эти поля в оффлайн
3. делаешь отдельную таблицу, в которой лежит uid из других таблиц. Назовём её таблица операций.
4. При появлении интернета ловишь ресивером это, идёшь в свою таблицу операций, достаёшь из неё метаданные(uid, название таблицы, тип операции (CRUD), название полей для синхронизации)
5. А дальше синкай как хочешь: можешь объект создать и его в джейсон, можешь еще как.
6. Удаляешь операцию только если отработал запрос.
7. Не отработал - кидай ошибку в UI, делай retry X раз

Ну и да, разделяй и власвтвуй, в одном файле это делать не стоит

Соответственно, в этой таблице операций также будут все запросы для создания чего-то нового? Например, чтобы добавить нового человека User(name="Bob", age="26"), мы сразу сохраняем его в таблицу БД Users, а в таблице PendingOperations на эту строку делаем ссылку. Теперь после появления интернета эта строка из  PendingOperations со всеми необходимыми данными будет выгружена на сервер. Я правильно понял?

https://www.enterpriseintegrationpatterns.com/patterns/messaging/GuaranteedMessaging.html
по пункту 6 в двух словах - гарантированая доставка

Спасибо всем!

BTW, коллега рассказывал, что они на работе на сервер-сайде в конце каждой транзакции складывают применённый патч в JSONB-поле специальной таблицы

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

Возможно может быть проблема в мерже данных, типа при появлении интернета появились данные по объекту с сервера. Это важно когда управление данными делится между несколькими пользователями (аналогия с мержреквестами). Тут уже продуктовое решение, а не техническое, ну и зависит от того как часто оффлайн происходит и как часто редактируются сущности одни и те же

У нас таким на клиенте на айоси занимались через протобаф, вроде до сих пор делают.

У меня сейчас только одно недопонимание. Например, нужно сделать продажу в интернет-магазине. Продажа, совершенная в оффлайне должна сразу записываться в таблицу со всеми продажами и соответственно появляться в статистике и тд?
Или эта оффлайн-продажа должна быть только в таблице с PendingOperations с указанием типа операции и всей остальной информацией для выгрузки в JSON-строке и при успешной синхронизации (т.е. успешный запрос на сервер) уже должна появляться запись в общей таблице для всех продаж?

Или это уже по сути опять же продуктовое решение/бизнес-логика?

што?

Продажа в интернет-магазине не должна происходить в оффлайне, здесь проблема бизнеса

Это не так. Но это уже оффтопик

к сожалению приходится иметь такую функциональность

Только в pabding operations, ведь не факт, что с появлением инета все пройдет успешно

Ну если я понял твой вопрос

А уже по резалту нетворк реквеста добавляй в стату