index
For details about indexes, see the App Indexing section. The following options can be specified for an index
tag:
on
required
Comma-separated list of field names. For belongs-to fields, use the name of the belongs-to field, not the model name (if different).
name
optional
Name to identify the index. Used for debugging purposes. Note that longer name decrease the performance of the index marginally
database
optional
app
, cloud
or app,cloud
. Defaults to app,cloud
when the cloud_indexes
feature flag is enabled. Note: With runtime versions before 4.79.0, this field is ignored, and indexes are always created in the app.
Supported Fields
Indexes are currently supported on the following fields:
belongs-to
text
integer
single-choice
single-choice-integer
date
datetime
boolean
Platform differences
The query engine and index implementation is different on web (browsers) versus other platforms (native Android, iOS and Windows containers). Make sure to test the performance on all targeted platforms.
On web, IndexedDB is used. Indexes are only used for = ?
queries - not for other operators or for sorting.
On other platforms, SQLite is used. Indexes could apply to most operators and sorting.
More details on how indexes are used in SQLite is available here.
For OnlineDB or CloudCode queries, the backend is used. Index usage would be similar to SQLite.
Performance Considerations:
Each additional index slows down writes to that model by a small amount.
Indexes need to be stored on the App DB, and the number of indexes multiplied by the number of objects (summed per model) will be proportional to the amount of storage required for the indexes. This can very quickly escalate to 100s of MB for models with multiple indexes and 10 000+ objects.
Last updated