execute
API method on the store
namespace as follows:
Using args to Query Dynamic Values
When dealing with data that may change dynamically during runtime, instead of defining the changing values directly in the querystring
, encapsulate them in a top-level args
object you can use to reference the values in your queries.
To pass an argument to the execute
function, use the :[argument]
syntax with DQL where the [argument]
maps to the field in the provided args
object.
For example, here color
is passed as an argument to the execute
function, and, within the query string, :color
placeholder references the color
defined in a top-level args
object.
SELECT * FROM cars WHERE color = blue
.
Managing Query Results
After executing a query, theresult
object that is returned includes both the overall content retrieved and individual items. Each item is encapsulated in independent QueryResultItem
objects that you can use to access them either directly or as raw CBOR or JSON data.
Rather than retrieving the items as part of the query execution and making them available immediately after execution, each item is lazy loaded. Lazy loading involves postponing fetching and storing in memory until requested on-demand or accessed later.
Here is an example query execution to select all documents from the cars
collection. The result is stored in the variable result. Then, each item is lazy loaded from the result object and stored in the items
:
Working with a QueryResultItem
The resultitems
object is a collection ofQueryResultItem
. Each item’s value can be independently managed to meet the needs of your scenario.
Value
To retrieve the value, call thevalue
property on an item:
Materializing the Value
To help manage memory usage more efficiently, content associated with anitem
is lazily loaded, meaning it materializes — loads into memory — only upon the initial call to value
.
To load the item’s value into memory, use any of the following methods as appropriate:
Raw CBOR Value
To access the result items as CBOR data:The result of this method call is not cached.
Raw JSON Value
To access the result items as a JSON-string:The result of this method call is not cached.
Diffing Results
This feature is available in v4.11 and above.
DittoDiffer
class that
allows you to opt-in to diffing only when necessary, thereby avoiding
unnecessary performance and memory costs.
However, diffing is computationally expensive. It requires storing the previous query
results in memory, leading to increased RAM usage, which can be particularly
problematic for applications handling large datasets or frequent updates.
Instead of computing diffs synchronously with every store observer update, it is
recommended to debounce diffing, processing changes out-of-band at a cadence
that best suits your use case.
Critical Memory Management: QueryResults and QueryResultItems should be treated like database cursors. Always extract the data you need immediately and then close/dematerialize them. Never store QueryResultItems directly between observer emissions as this will cause memory bloat and potential crashes.
DittoDiffer
is given query result items and compares them to the previous set of items it has received:
diff()
method returns a DittoDiff
containing:
insertions
: Indexes of new items in the new arraydeletions
: Indexes of items that were removed from the old arrayupdates
: Indexes of items in the new array that were present in the old array and whose value has changedmoves
: Pairs of indexes showing items that changed position
Example: Apple UIKit
Use this diff to update a UIKit class, such asUITableView
, UICollectionView
:
Swift
Key considerations
- Keep references to arrays yourself: The differ doesn’t provide access to the old and new items themselves, so they need to be retained by the user if needed.
-
No comparison of document metadata: The differ performs a deep comparison of the value of each query result item but doesn’t take into account any metadata. Applying a series of changes to a document will not cause it to show up in
updated
unless those changes result in a different value from the initial state to the final state. - No async diffing: Computing a diff on a set of many query result items or very large query result items might block the device depending on its hardware.
Migrating from Live Query Events
If you’re using the legacy live query API that automatically provides diff information throughevent
parameters, you can migrate to the newer store observer pattern with the DittoDiffer
class. The differ provides equivalent functionality but requires manual management of previous results.
For a complete migration guide, see Replacing Live Query Events with Store Observers.