FAQs
Last updated
The user object is likely not being synced to your device. It is important to remember to explicitly sync the user object. This can be accomplished by defining a bucket that has the root of "self", since root objects are included in buckets.
Alternatively, if you require access to user objects globally, you can sync them via a global bucket:
has-many/model references within my data rules?No, this is not currently possible.
As a workaround, you could create a new field that is set based on a combination of fields that make up the condition, and then set the condition attribute to this new field.
The exact processing time varies based on the app and the server load, but it usually takes around 1-2 seconds per 1000 entries in the , or half an hour per million entries.
Yes, sync rule reprocessing has no impact on the Backend API.
By default, attachments are synced on demand and cached locally on a user's device. The demand is triggered whenever the app tries to access the attachment programmatically, either using a view component (e.g. display-photo) or by trying to access it from JS/TS (for example using journey.files.viewFile(someAttachment)). At that point the device will try to access the attachment from local storage and, if not available, download the attachment from the AttachmentStore and cache it locally to use in subsequent requests. If no internet connection is available, the attachment will not be downloaded and there will be no attachment to interact with.
Attachments that are created on the device will automatically be cached on the device. Finally, all cached attachments eventually get uncached / desynced on a first-in-first-out basis.
You cannot set up data rules for attachments, only for the objects that hold the references to the attachments. So if you have a model called photo that has a field for a photo attachment and a text field for a name, then you can setup data rules for your photo objects but not for the actual photo attachments.
For example, your data model:
And your data rules:
This would sync all photo objects with photo file references, but not the actual photo files. Those would only get “synced” once you try to use them in the app.
await DB.user.all().count(); –> This should return only users where archived != true
await OnlineDB.user.where(archived != ?, true).count(); –> this will return the count that you are expecting
If those counts don’t look correct, we suggest diving into the sync rules definitions to ensure that the user object (using the above example) is not synced in an additional bucket without the archiving condition rule in place. We also suggest checking that your current user role and/or permissions are set up correctly with the data rules you are testing.
For read/write access ACLs we suggest testing OnlineDB calls specifically. For example, if your user model has a read="offline" data rule, you should not be able to query the user model using OnlineDB:
await DB.user.all().count(); –> This should return all users, since all users are being synced
await OnlineDB.user.all().count(); –> This should return no results, since OnlineDB access is disabled.
Attachments (, and ) are stored separately to the "standard" DB (where your app's data objects are stored), namely in an AttachmentStore. What is stored in the DB is a reference (an Attachment ID) to the entry in the AttachmentStore. A byproduct of the separate storage is that attachments are not synced automatically with the rest of the data. The reason is to limit unnecessary network traffic / data usage.
A good way to debug data rules is to open up the and run some tests on the object counts. For example, if you are archiving the user model and syncing all users except for the archived ones, you can compare the backend data browser count to what is returned in-app for:
Also see on what responses to expect when access is denied.