GraphQL Replication Plugin: Allow syncing revisions

[gautambt]

This PR fixes #1830

I've added a new flag syncRevisions. When this flag is set:

1. pushQueryBuilder gets additional fields _rev & _revisions
2. runPull function will use the _rev & _revisions fields received from remote graphQL endpoint as is (without generating new versions)
3. All documents synced from remote have _replication_id set to the revision_id. This is used to filter them out while fetching changes to be pushed to the remote

[gautambt]

@pubkey When I run the tests on my local using "npm run test:node" or "npm run test:fast", the tests seem to be passing. Any idea?

[pubkey]

Can you delete your local test_tmp and .transpile_state.json and then try again?

[gautambt]

@pubkey Thanks! That worked. Have fixed the tests now.

[pubkey]

@gautambt sry for the late response.
Thank you for the PR. I checked the code and all looks good.
But there is one thing I would like to change. The field _replication_id is currently hard coded, I propose to let the user define the field when starting the replication. Also the user is responsible for defining the field in the schema. This makes things less complex as for example RxDocument.toJSON() does not return an internal field. Also it would make it possible to replicate with multiple servers at the same time, each one having a different revision field. But most important for me is that we do not write plugin specific code into RxDB's core. I have done this too often in the past and I am currently it refactoring out plugin stuff from the core at the 9.X.X branch.

[gautambt]

@pubkey Agree that it is better to not have plugin specific code in the core. I can change the _replication_id field to be user-configurable. However, in this case, the user will have to manually declare the field in the schema. Otherwise, when the user loads a document with this field set, the schema check will fail. Is this developer experience okay? Since the field is completely internal to the plugin I am wondering if it is possible to remove it when the document loads via some kind of a hook.

[pubkey]

@gautambt yes I would be okay with the dev experience when the user has do specify which field is used as revision.
Your approach of totally removing it internally sounds promising. At the moment we have these hooks which can be used by plugins. Of course we can add any hook to the core that makes sense.

Depending on how much time you have, it might be better to add the first solution now and later migrate to using the hooks to handle everything internally. For the next version 9.X.X I am rewriting a lot of internal stuff so it should be easier to add the internal handling afterwards.

[gautambt]

@pubkey Have renamed _replication_id to last_pulled_rev, made it configurable and remvoed changes to the core. Please have a look.

[pubkey]

I merged this now. I also added it to the changelog. It would be cool if you could update the documentation.

[MentalGear]

Thank you for your work on this @gautambt (and of course @pubkey for this great offline-first db!).
Forgive me to ask this here, but I couldn't find a clear answer in the documentation.
When using the graphQL endpoint, what other things would be necessary to manually integrate to get the full features of couchDB (like sync, automatic conflict resolution, etc)?

[gautambt]

I had written a blog post at that time that might be useful: https://hasura.io/blog/couchdb-style-conflict-resolution-rxdb-hasura

[MentalGear]

Thx for the blog post ! If I understand correctly, there's no out of the box solution and one seems to need to replicate the desired conflict resolution manually client and serverside.
While I'm grateful for the description, I'm a bit anxious if this could cover all scenarios (besides overwritting all revisions as deleted) and wonder if there could be something like couchDB's auto resolution for graphQL.