Hm, but CBLQuery.h does not provide a property “offset” ? Well, at least not my version (couchbase-lite-ios-community_184.108.40.206).
// Created by Jens Alfke on 6/18/12.
// Copyright © 2012-2013 Couchbase, Inc. All rights reserved.
@interface CBLQuery : NSObject
/** The database that contains this view. /
@property (readonly) CBLDatabase database;
/** The maximum number of rows to return. Defaults to ‘unlimited’ (UINT_MAX). */
@property NSUInteger limit;
/** The number of initial rows to skip. Default value is 0.
Should only be used with small values. For efficient paging, use startKey and limit.*/
@property NSUInteger skip;
/** Should the rows be returned in descending key order? Default value is NO. */
@property BOOL descending;
/** If non-nil, the key value to start at. */
@property (copy) id startKey;
/** If non-nil, the key value to end after. */
@property (copy) id endKey;
/** If non-nil, the document ID to start at.
(Useful if the view contains multiple identical keys, making .startKey ambiguous.) /
@property (copy) NSString startKeyDocID;
/** If non-nil, the document ID to end at.
(Useful if the view contains multiple identical keys, making .endKey ambiguous.) /
@property (copy) NSString endKeyDocID;
/** If YES (the default) the startKey (or startKeyDocID) comparison uses “>=”. Else it uses “>”. */
@property BOOL inclusiveStart;
/** If YES (the default) the endKey (or endKeyDocID) comparison uses “<=”. Else it uses “<”. */
@property BOOL inclusiveEnd;
/** If nonzero, enables prefix matching of string or array keys.
* A value of 1 treats the endKey itself as a prefix: if it’s a string, keys in the index that
come after the endKey, but begin with the same prefix, will be matched. (For example, if the
endKey is “foo” then the key “foolish” in the index will be matched, but not “fong”.) Or if
the endKey is an array, any array beginning with those elements will be matched. (For
example, if the endKey is , then [1, “x”] will match, but not .) If the key is any
other type, there is no effect.
* A value of 2 assumes the endKey is an array and treats its final item as a prefix, using the
rules above. (For example, an endKey of [1, “x”] will match [1, “xtc”] but not [1, “y”].)
* A value of 3 assumes the key is an array of arrays, etc.
Note that if the .descending property is also set, the search order is reversed and the above
discussion applies to the startKey, not the endKey. */
@property NSUInteger prefixMatchLevel;
/** An optional array of NSSortDescriptor objects; overrides the default by-key ordering.
Key-paths are interpreted relative to a CBLQueryRow object, so they should start with
"value" to refer to the value, or “key” to refer to the key.
A limited form of array indexing is supported, so you can refer to “key” or “value” if
the key or value are arrays. This only works with indexes from 0 to 3. /
@property (copy) NSArray sortDescriptors;
/** An optional predicate that filters the resulting query rows.
If present, it’s called on every row returned from the query, and if it returns NO
the row is skipped.
Key-paths are interpreted relative to a CBLQueryRow, so they should start with
"value" to refer to the value, or “key” to refer to the key. /
@property (retain) NSPredicate postFilter;
/** Determines whether or when the view index is updated. By default, the index will be updated
if necessary before the query runs – this guarantees up-to-date results but can cause a
delay. The “Never” mode skips updating the index, so it’s faster but can return out of date
results. The “After” mode is a compromise that may return out of date results but if so will
start asynchronously updating the index after the query so future results are accurate. */
@property CBLIndexUpdateMode indexUpdateMode;
/** If non-nil, the query will fetch only the rows with the given keys. /
@property (copy) NSArray keys;
/** If set to YES, disables use of the reduce function.
(Equivalent to setting “?reduce=false” in the REST API.) */
@property BOOL mapOnly;
/** If non-zero, enables grouping of results, in views that have reduce functions. */
@property NSUInteger groupLevel;
/** If set to YES, the results will include the entire document contents of the associated rows.
These can be accessed via CBLQueryRow’s -documentProperties property.
This slows down the query, but can be a good optimization if you know you’ll need the entire
contents of each document. */
@property BOOL prefetch;
/** Changes the behavior of a query created by -queryAllDocuments.
* In mode kCBLAllDocs (the default), the query simply returns all non-deleted documents.
* In mode kCBLIncludeDeleted, it also returns deleted documents.
* In mode kCBLShowConflicts, the .conflictingRevisions property of each row will return the
conflicting revisions, if any, of that document.
* In mode kCBLOnlyConflicts, only documents in conflict will be returned.
(This mode is especially useful for use with a CBLLiveQuery, so you can be notified of
conflicts as they happen, i.e. when they’re pulled in by a replication.) */
@property CBLAllDocsMode allDocsMode;
/** Sends the query to the server and returns an enumerator over the result rows (Synchronous).
Note: In a CBLLiveQuery you should access the .rows property instead. */
- (CBLQueryEnumerator*) run: (NSError**)outError;
/** Starts an asynchronous query. Returns immediately, then calls the onComplete block when the
query completes, passing it the row enumerator (or an error). */
- (void) runAsync: (void (^)(CBLQueryEnumerator*, NSError*))onComplete attribute((nonnull));
/** Returns a live query with the same parameters. */
- (CBLLiveQuery*) asLiveQuery;
The explanation of “skip” sounds slow and CBLQueryEnumerator::indexAtRow is actually slow.
Here is what I do … I retrieve the keys of the current visible (table) elements. If the first entry changes the current visible key elements are retrieved/updated from the database. Thus there is one query of x elements (presented elements) if the rows change. The retrieval is done with a startkey and limit. And I like to speed up things a little more. Any suggestions?