Hi
Another option is to have a per user database option. It is far more
efficient for replication. Then have a server side process that is
triggered and saves the documents into the the right database. We have
implemented a type of transaction management module that helps with
conflct resolution, and makes sure that all documents in a given
"transaction" save successfully. Relying on replication only, unless
your documents are completely atomic and do not depend on any others to
be too complicated, and not effective.
Regards
Willem
On 2019/10/12 15:55, Sebastien wrote:
Thanks Stefan,
Indeed my plan is in any case only to expose a limited set of properties,
certainly not the full user objects.
Good point about separating user account from person and personal
information.
Following your idea, I could imagine having a bare bones _users database
with only the accounts, allowing me to authenticate users (already in place
now).
Next to that I could have a separate "persons" database containing personal
information; there would in that case be a 1:1 mapping between a document
in _users and one in "persons".
Taking that as starting point, one option could indeed be as you propose to
copy a subset of that "persons" database into each other database (of
course again only a subset of the info, ideally controllable by the end
users). One problem that I imagine with that is mainly the amount of
incurred data duplication.
More importantly the chaining of changes/replication could be really
important with that when a user changes something on his/her profile, as
the data would need to be copied again to each matching database and
replicated to each client needing that information.
For now I think that having a single "persons" database and replicating it
(filtered) to each end user for offline use is the way to go. I just need
to figure out how to handle the filtering and if data that shouldn't be
there locally will be removed automatically or not.
For instance, imagine that persons contains [A, B, C, D, E, F], then:
- If [A, B, C] have access to database X, then those users should have a
copy of [A, B, C] locally
- If [A, D, E] have access to database Y, then those users should have a
copy of [A,D,E] locally
Consequently, A should have A, B, C, D, E in his local "persons" database
copy.
If at some point E is removed from database Y, then user A should not have
E in his local database anymore.
Does that sound like something that can be handled through filtered
replication?
I hope that my system will be able to handle hundreds/thousands of
databases with 1-100 users in each database; each use having access to
~1-10 database, thus potentially having access to ~1K user documents
locally (thus is really just an early guesstimate).
The system currently doesn't allow users to manage their own profile but
it's indeed a requirement. I'll probably only allow users to modify their
own information while online through a dedicated API endpoint checking the
user's identity instead of letting them directly write to the "persons"
database.
Sébastien.
