❔
FAQs
I have implemented data rules, and no longer have access to the user object. What could have caused this?
user object. What could have caused this?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.data_rules.xml
<bucket via="self">
</bucket>
Alternatively, if you require access to user objects globally, you can sync them via a global bucket:
data_rules.xml
<global-bucket>
<model name="user" />
</global-bucket>
Is it possible to have more than one condition for the has-many/model references within my data rules?
condition for the 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 Oplog, or half an hour per million entries.
Yes, sync rule reprocessing has no impact on the Backend API.
Attachments (photos, signatures and files) 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.
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:
schema.xml
<model name="photo" label="Photo">
<field name="name" label="Name" type="text:name" />
<field name="photo" label="Photo" type="photo" />
<belongs-to model="user" name="user" />
<display>{name}</display>
</model>
And your data rules:
data_rules.xml
<bucket via="self">
<has-many name="photos" />
</bucket>
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.A good way to debug data rules is to open up the debug console 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: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 expectingIf 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 syncedawait OnlineDB.user.all().count(); –> This should return no results, since OnlineDB access is disabled.
Last modified 1yr ago