I am trying to understand from the documentation the lifecycle management of flexible sync subscriptions.
I was just implementing a view and was getting all data I had read access to, even though I had added a ‘$0.owner_id = user.id’ parameter to the initialSub block for it. I wanted to list only this particular user’s data in this view.
Eventually, I deleted the app and data and reinstalled the app, and now I have the expected dataset.
I understand that initial subscriptions are relatively static and need to be updated or rerunOnOpen, but I think I misunderstood the lifecycle of subscriptions entirely. I thought rerunOnOpen was necessary if the sync session is still active and the app is restarted. I assumed that if the sync session was not active (user has been offline for days), then it would need to establish a new subscription (session).
I’m now thinking that for the purposes of subscription lifecycle, it is considered still existing if the sub’s dataset still exists in the realm (which it would pretty indefinitely if the user hasn’t used the app in a long time). The lifecycle has nothing to do with actual session activity?
Hey @Joseph_Bittman - assuming you’re talking about the Swift SDK, I believe it works like this:
The subscription is on a given realm. The subscription itself persists until you explicitly unsubscribe, or use updateQuery to update it. If you have a subscription in an initialSub block, but you do not set rerunOnOpen to true, the initialSub essentially gets ignored if a realm matching the configuration already exists on the device. That block checks for an existing realm, and if one exists & it’s not re-running on open, it won’t run. The use case for initialSubscriptions is to bootstrap a realm with data that must exist when an app starts, but you don’t expect the subscription to change necessarily. Think something like loading a public catalog of data as in an ecommerce app. I think Swift is the only SDK that has initialSubscriptions that work like this; eventually this feature may come to the other SDKs.
If you need to manage subscriptions more dynamically, and you don’t need an initial data set when your app opens, you might be better served using the other subscription APIs to manage your subscriptions.
The objects that sync based on the subscription are subject to a user’s read and write permissions. Those permissions are evaluated at the beginning of a session. If a user’s permissions change between sessions, that should change the objects that sync to that user’s realm. So that’s how sessions come into play, but otherwise they don’t affect the subscription.
Do you know how the following situation is handled?
Given swift view1 has an ObservedResults that subscribes to all X objects
Given swift view2 has an ObservedResults that subscribes to some filtered set of X objects
When a user navigates from view1 to 2 and back
Then does two subscriptions exist or a single subscription that keeps getting updated on the filter?
If only one subscription, and its filter keeps being updated, then is it wiping and pulling down the full dataset each time the user navigates back and forth?
Does the same answer hold if I add into the mix an initialSubscription that pulls down the entire dataset when the app loads the first time (like a product catalog).? It would be nice to not accidentially re-create the subscription by accident and have needless delay in data being pulled. I have some pre-existing views that I’m trying to understand if I need to re-work how they query data…
Ah! Are you using the awaitable ObservedResults Flexible Sync API? If yes, those are two separate subscriptions. I was just talking with the engineers and product owner about a similar case a few days ago.
So here’s my understanding, and @Diana_Maria_Perez_Af or @Jason_Flax can feel free to add details if I’m missing anything important:
Say View 1 subscribes to all Dog objects. And View 2 subscribes to Dog objects where age < 2. That’s technically two subscriptions, but the data that is in the realm shouldn’t change, because View 1 has a subscription to all Dog objects.
What I am uncertain about in this particular case is what happens when an object goes “out of view” of a subset subscription query. In this example, if a Dog’s age changes and now he’s 3, I would expect him to not be visible in View 2, but would expect him to still exist in View 1 because that’s a superset of the data. So the object should still be in the realm since it falls within Subscription 1. Subscription 2 in this case should probably not be a subscription at all, but the plain old ObservedResults to just query from the superset established in View 1.
I asked about a similar case where ObservedResults subscriptions did not overlap. So in that case, View 1 might subscribe to all Dog objects where Age <= 2, and View 2 might subscribe to all Dog objects where Age > 2. So when an object falls out of the results set of View 1, it is technically unsynced because it’s no longer part of the subscription set - and subscription 2 syncs it again, because it becomes part of that subscription set. In that case, the object would be removed from the realm but immediately re-added because it’s part of the other subscription.
If you have an initialSubscription that pulls down the entire data set that your app needs, and your subsequent views are just using data that is contained in the initialSubscription, the subsequent views should probably not be subscriptions at all, but should just be ObservedResults queries to get the data that was pulled down in the initialSubscription.