index
For details about indexes, see the App Indexing section. The following options can be specified for an
index tag:Name | Required | Details |
|---|---|---|
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_indexing feature flag is enabled. Note: With runtime versions before 4.79.0, this field is ignored, and indexes are always created in the app. |
Indexes are currently supported on the following fields:
belongs-totextintegersingle-choicesingle-choice-integerdatedatetimeboolean
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.
For OnlineDB or CloudCode queries, the backend is used. Index usage would be similar to SQLite.
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 modified 1yr ago