[questions] migration + space + production

[hyusetiawan]

as I am developing locally, I am making big changes to the schema, key, and data returned. I wonder what's the best way to "reset" the stale data? currently, I have to manually clear the browser if not the mutations that have failed would get retried, which makes it hard to debug. This also applies when I reset the database, the stale local mutations would get pushed and fail.

Related to resetting the stale data, what's the best practice once it's deployed to production and we would have to do a "migration"? Say that we are changing the shape of the objects we synced, or deprecating some objects, or maybe changing the way structure of the key.

Is there a best practice as well to structure the "Space"? My current understanding is that space contains ALL the things that need to be synced so it sounds to me, each user would have 1 or more spaces? For example, a user can be in multiple chat rooms, each chat room should be a space of its own?

In the remote schema documentation, soft delete is mentioned but I cannot find more documentation about it, any guide on how to implement this?

[aboodman]

as I am developing locally, I am making big changes to the schema, key, and data returned. I wonder what's the best way to "reset" the stale data? currently, I have to manually clear the browser if not the mutations that have failed would get retried, which makes it hard to debug.

The "clear application data" button in your developer tools is the easiest way to completely wipe client state. It will delete pending mutations and delete your local state, starting fresh.

For mutations in particular, we also recommend while you are early in development skipping failed mutations on the server: https://doc.replicache.dev/server-push#error-handling. In this case, the failed mutations will be ignored and not retried.

Related to resetting the stale data, what's the best practice once it's deployed to production and we would have to do a "migration"? Say that we are changing the shape of the objects we synced, or deprecating some objects, or maybe changing the way structure of the key.

Increment the schemaVersion that you construct replicache with. This will create a new instance of local state and pull a fresh copy of the client view. The schemaVersion is sent in the pull request as well (https://doc.replicache.dev/server-pull#schemaversion) so that you can handle both client types while the new version is rolling out.

[hyusetiawan]

would like to share the research that I have done on spaces for people stumbling upon this thread:

1. you can have multiple spaces but each table/resource can only exist in 1 space, multiple spaces cannot track the same table/resource
2. join the discord channel, there is a more complex design to recreate Discord as a product, I think this should be included in the main doc.
3. there is a roamresearch link in the discord as well that talks more about auth, paging data in and out, and other conceptual thinking for replicache, it links to @aboodman 's personal link.

[aboodman]

Technically you can have a piece of data that is in two spaces, however you would have to correctly increment the version on each space that it is a part of whenever that data changes. Which would reduce the transactional throughput of spaces. I don't recommend doing this.

[aboodman]

There should be a top-level doc about spaces for sure.

Created: ~https://github.com/rocicorp/mono/issues/51~

Edit: meant that issue to be public: https://github.com/rocicorp/replicache/issues/1035

[hyusetiawan]

Technically you can have a piece of data that is in two spaces, however you would have to correctly increment the version on each space that it is a part of whenever that data changes.

does this mean, if we have multiple spaces, in the clients table we would need to track which space as well? ex in Prisma:

model Client {
  pid            String @id @db.Uuid
  space String
  lastMutationId Int

  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

[aboodman]

I don't think so? What are you thinking?

[hyusetiawan]

nevermind, I think I mistook versioning with mutation id, my thinking was, each space will have its own version, doesn't that mean that the mutation has reached up to that version as well? but if that is the case then there will be repeated mutations run on the server. If i understand correctly, the pairing of mutationId and client is to know whether to run the mutation on the server side?

[aboodman]

The lastMutationID and space version have nothing to do with each other.

The naming is somewhat confusing and I apologize for that, the names date to a time when there was more flexibility in Replicache and they made more sense in that context.

But it's really just two version numbers -- one for the client and one for the space:

• Each client sends a stream of mutations to the server over its lifetime, each identified by a sequence number. That's their mutationID. The lastMutationID on the server is the last of these the server has processed. It needs to track this for each client to make sure the mutations play in order.
• The space also has a version. Each time the space is modified by a mutation (or perhaps by a batch of mutations) the version ticks forward. The server has to track the version so it can compute diffs when clients ask. The client has to track the space version so it can send it in pull requests to get changes.