I have some questions to help plan development (knowing it is in Preview and not GA).
Am I correct, in my assumption that eventually (i.e., once out of preview) Flexible Sync can be ran with Partition-Based Sync in the same Realm App?
Do you have a GA date estimate? - or even when we can test with both Partition Sync & Flexible Sync in same Realm App.
Will the limit of 10 Queryable Fields be changeable in future (or handled by a cost factor)? -to avoid using generic names like ‘queryField01’ across classes.
Will the embedded object or current operators in RQL Limitations for Flexible Sync change by GA or soon after? -If so, can you disclose which are likely?
With ‘superseded’ is there a suggested wait time to handle before acquiring query state again (assuming connected and all)?
Out of curiosity, if a query is duplicated in a SubscriptionSet, which will prevail first or last written?
Document typo found:
I believe the words in the name are transposed for QuerySubscription (written as SubscriptionQuery) in first paragraph of API reference: QuerySubscription Structure Reference
Roop, welcome back! - I told you we’d get there eventually!
I am working on a design that should hopefully allow partition-based sync clients to automatically convert their requests to a flexible sync query. I feel like this should be obtainable because you could potentially think of a partition-key request as the simplest flexible sync query ever - ie. give me all documents on all sync collections where this field equals this value. I don’t have approval yet but I am pushing for it so stay tuned. At this moment a Realm Sync App is either partition-based sync or flexible sync.
I hope to go GA this year - the more people use it, the more comfortable I will be in making this decision earlier
We can change this limit if needed but be advised that this will inflate your storage costs the higher you go - its not linear but should be considered. I would also think that if you need a ton of queryable fields that something is off in your schema design or query patterns and you should probably reconsider your architecture - happy to meet and discuss though
Embedded objects and queries on Arrays for Flexible Sync are currently being worked on right now and will be there for GA. Anything else you are looking for?
Generally, you should try to avoid this because there is no point - a duplicated query may make the server do more work, but should otherwise not change your results.
Hey Ian – yes you did - glad to see Flexible Sync! Hope all is well.
That sounds interesting to use the partition key. I have some suggestions, if it is something you’d like to discuss LMK. That could be handy since anything that was QBS that I cannot convert to Flexible (for now) - would be Partition-Based via Permissions. For now, it sounds like one way or another we will be able to use then both together in a Realm App . Is it safe to say by the first GA?
That’s not so bad – thanks!
OK. Would something like a declaration attribute on class properties (instead of defining queryable fields) give flexibility to developers yet help prevent storage bloat?
Yeah, currently my queries use all the unsupported operators. If I had (had to had to) choose some they would be: [c], IN, beginsWith, contains, ANY.
Thanks.
Of course will avoid, just wanted to make sure last written prevails[?].
Hi, good thing is that most of the string operators will be implemented and released very soon (beginsWith, contains, [c], endsWith, like). The array operators like ANY will be followed up quickly after and we can ping this thread when they get released if that works. Out of curiosity, when you say you want to use IN, do you mind letting us know what your query is intended to look like? There are two different interpretations with IN depending on if the right-hand side of the query is a string or a list of elements you are trying to OR together.
Hey, I’m not sure I follow you 100%. We are planning on rolling out support for querying on Realm Collections using the ANY, ALL, NONE syntax in RQL within the next quarter hopefully. Is that what you are referencing?
I’m not sure what your use case is but I what I was mentioning above was to have some sort of way to convert partition-based sync clients to a flexible sync configured on the cloud side. The cloud side would only be configured with flexible sync - we haven’t started this work yet, it is likely a few quarters out.
Thanks for that and it’s understood. Though, my main focus is on the ability to have both (Partition & Flexible) in same App. If that is going to happen? -because if not, managing 2 Apps per user won’t be fun .
Currently, I have 3 main designs for Realm with MongoDB, that I have separated as follows:
Partition-based with EmbeddedObjects. When using EmbeddedObjects I will NOT have a relationship in Schema, this way the entire Object or List<> will be written in as the embedded value.
–a) This will be for when user will have a copy an Object to EmbeddedObject, since want to preserve the ‘_id’ → ‘id’ value across objects (no duplicate ‘_id’ in a Collection).
Partition-based without EmbeddedObjects. Using relationships via foreign_key references as the nested value.
–a) This will be for simple user partitions, complex user partitions (via parsing ‘_id’ for further partitioning) and global partitions (for all users).
Flexible Sync. To replace most of Legacy Realm’s QBS and which would be too burdensome to have on Partition-based.
What about offering ability to add multiple Atlas-DBs (e.g.: one for Partition and one for Flexible) to a single Realm App via separated Syncs (could even have separate App-IDs) This way there would only be 1 user to manage (since 1 Realm App). Of course, the Collections may be duplicative but that would be the case anyhow. Each Sync in the Realm App would be either Partition-based or Flexible.