I’m implementing a setup with a public channel and one channel per user - the latter includes some “private” information for the user who logged in.
If a user logs off - and another user logs into the app on the same device then Sync. Gateway will replicate some other documents specific to the new user. But what happens with the previous user’s “private” documents?
I guess that the documents will stay “untouched” by the replicator. Can I delete them locally when switching user - without any effects on the server side? The users do not have access to each other’s private documents (the sync. formula would be the place to enforce that, right?)
I actually talked about this during my “best practices” talk at Couchbase Connect last month.
You should create a new local database for each user that logs in. Otherwise one user’s docs will be left behind and end up as visible to another user when they shouldn’t be.
… interesting, @jens … Is there a recording of your talk?
I have many documents that are “public” - and then just a few that are personal. Some of the user’s documents are also public.
So putting the “personal”/private docs in a separate local database would to some extend be “cumbersome”. And how would it solve it? Apart from deleting the local database?
Yup, I found a recording. My portion is the middle 1/3 of the talk.
putting the “personal”/private docs in a separate local database would to some extend be “cumbersome”
No, you only use one database at a time. All the documents go into that database. You can name the database after the user’s ID, for example. When a new user logs in they’ll start with an empty database, but the replicator will bring in all the docs relevant to that user. This way you don’t get any pollution of sensitive data between users.
Ah Ok, but that wouldn’t fit well with this app as there are many public docs. And that would mean that the same docs would need to be re-sync’ed again.
But I do get your point and I will have a look at using that concept e.g. combining it with a “pre-populated” database for first time setup. That would make the switch less painful (=time consuming)
If you have a lot of public documents to be shared across users, you can put it in a separate “common” database. Then you have a user specific private database for each user for documents that are sensitive. Especially if the number of public documents are large , wouldn’t make much sense to sync them down for every user of the app.
It looks like this is what you were proposing initially. Not sure I understand what the concern is. As long as you don’t expect to query across the databases, it should be fine.
Of course, if these public documents are known upfront, then you can load it using pre-built database as suggested above, but then again, if you have many users sharing the app on the device, you will have redundant data .
Ok, I see that I made my question a little too generic (to avoid bringing a lot of details).
I have split e.g. the user information into two documents:
id: User:1234
id: User:Private:1234
The latter contains personal information. The first one only contains information about “interests” that can be used for creating stats in the app. Therefore, for user 1234 I’ll have all ordinary user documents and one private user document.
So when user 1234 logs off and user 4321 logs in I’ll need to remove the private doc for 1234 and sync the private one for 4321.
My guess is that if I log into the app as another user than last time then I could find and remove the “private” docs for any previous user - and that these deletions would not be sync’ed back to the server as the user key of those documents (1234) would not match the currently logged in user (4321).
… and my question is whether this “deletion” would cause any trouble say if user 1234 logs into the app again?
I estimate that more than 95% of the docs would be “public” (or impersonal) and would need to be available for all users. I don’t think it will be a normal use case that users will log off and another log on using the same device - but we think this could happen - and, therefore, I need to handle it properly
I think you are overcomplicating this. Just use two databases for each user:
public.cblite2 which contains data from your “public” channel
<username>.cblite2, where the name depends on the logged in user and will only sync the documents that the user specifically has access to (i.e. the ‘username’ channel). That way one user will never see another’s private documents.
I will need to work on data from both “data types” together. And from what I understood from comments above then that would require them to be in the same database.
I fully understand the idea of separating the data sets into two databases - and the benefits from doing that. However, I still don’t have an answer to what will happen when deleting docs in a database that the current user does not have access to delete on the server (I guess those deletions would just be ignored by the sync. gateway) - and especially in the case where the previous user logged in again. What happens with those docs that were deleted by the intermediate once the user with access to them logs in again?
Have the deletions been ignored so the original docs for this user will be synced down from the server?
Are the deletions “pending” so that they are sent to the server again - but now (unintentionally) working?
Don’t delete docs! Deletions are replicated, so you’ll be deleting them everywhere.
What you want is a purge, which locally deletes a document leaving no trace of it.
However, IMO trying to purge the private documents is dangerous. If the db schema changes later on and you forget to update the code that does this purging, you can end up leaving sensitive docs behind when switching users, causing security/privacy problems.
… and I agree with you on the risks - but I need to understand what’s going on behind the scenes to create the right solution.
The private docs described above is one scenario - another is photos. Some photos are deliberately made “public” by users - and those that are not are private to the current user. Some of the current user’s photos can also have been made public. So putting these in two different databases poses other problems…
But thanks for the insights - now I can try to find the most robust solution with the smallest disadvantages
I’m still new to this platform - so that’s the reason for all of the “silly questions”
