Open excursus opened 1 year ago
Replicache itself doesn't track a version per domain object -- it thinks of the entire client view as one entity that moves atomically.
Replicache does track the version of the client view that it has, and it is sent as the cookie
in pull requests. The cookie is opaque and can contain any information the server wants. Broadly it's used by the server to encode the version the server was in when a pull was returned, however the server wants to represent that.
In the row versioning strategy, the cookie is a key to a larger structure stored server side which indeed encodes the version of every entity independently. So if you had the cookie in the push request, and if you were using the Row Versioning strategy or something similar you could know what version of an entity the client made changes to.
Sadly, the cookie isn't sent in the push request. Perhaps it should be. But it's easy to workaround this. You can provide a custom pusher and puller implementation. The puller can snarf the cookie out of the response each time a pull is sent and stash it someplace, and the push can add the cookie to the request.
We're trying to think about conflicts and merge strategies, so we're wondering whether it's possible, during a push, to know the last version number that the client knew a domain object to be in. On the server this would be useful information because if: 1) the client's last known push version coincides with the server's version, then there are no merge conflicts so it's safe to do a plain write. 2) if the existing server version is greater than the client's last known push version, then some other client has made changes, so applying a merge is in order.
Is it possible to obtain this version from the client? Is this something that the client itself must track, maybe by storing it in a mutation?