You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Both the one-off and realtime pull handlers could add WHERE clauses to only fetch a subset of the table. The important restriction on the WHERE clause here would be that rows must never leave that "partition" of the table, otherwise the pull handler wouldn't get notified about that "deletion".
This would basically enable subcollections like in Firestore. To implement this safely, the ID of the subcollection wouldn't actually be part of the RxDB, but rather the user would create one RxDB per subcollection they want to track and then pass that ID to SupabaseReplication.
The text was updated successfully, but these errors were encountered:
Both the one-off and realtime pull handlers could add WHERE clauses to only fetch a subset of the table. The important restriction on the WHERE clause here would be that rows must never leave that "partition" of the table, otherwise the pull handler wouldn't get notified about that "deletion".
This would basically enable subcollections like in Firestore. To implement this safely, the ID of the subcollection wouldn't actually be part of the RxDB, but rather the user would create one RxDB per subcollection they want to track and then pass that ID to SupabaseReplication.
The text was updated successfully, but these errors were encountered: