I have the following “recipe” in a POC:
- iOS Objective C code (primarily)
- CBLite 1.3.1-6 installed using the standard copy-framework method
- Storage engine set to kCBLForestDBStorage
- View created by mapping a set of documents, looking for an ID prefix (e.g. “activity:1234” looking for “:activity”), returning a string-date “created” field for those activity records. This is a server-set value in the form “2016-10-28T22:30:23.000Z”.
- LiveQuery created by calling createQuery with the above view’s name, setting descending=YES and limit=300 on it, then getting it as a livequery.
- CBLUITableSource configured to use the above liveQuery.
- Background thread communicating with server, updating the above-mentioned objects as new ones are created on the server. This uses a background manager copy as described in http://developer.couchbase.com/documentation/mobile/1.3/guides/couchbase-lite/native-api/manager/index.html#running-couchbase-lite-on-a-background-thread.
- Records are updated using the “doc update:” block callback method described in http://developer.couchbase.com/documentation/mobile/1.3/guides/couchbase-lite/native-api/document/index.html#updating-documents (the second method there).
We are NOT using the CB Sync facilities - we’re evaluating those, but this is a POC for CBLite itself and we have a lot of existing sync code so we’re just tying into that. (The application currently uses Realm.)
Here’s what we are experiencing. When we FIRST start the app and open this view, the results are correct and sorted properly. However, as soon as the server sends a list of updated records, the table begins to show data out of sort order.
The current sync protocol is not very smart - it sends more data than it needs to. So it may re-send records even if they don’t need to be updated. But even so, we would expect that an in-place update of a document, basically setting fields to their current/already-set values, would not affect the index. Instead, the updated records are bumped to the top of the tableview, disregarding the original sort order of the view/query.
Is there an approved/expected pattern for this type of operation?