Skip to content

Avoid committing no-ops #616

Open
Open
@alecgibson

Description

@alecgibson
Collaborator

At the moment, if you submit a no-op (or two ops collide, resulting in one of them being transformed into a no-op), ShareDB will commit this to the database.

This has some downsides:

  • pointless DB writes
  • can cause unneeded retries if other ops are submitted at the same time, which wouldn't need to be transformed because it's a no op, but they still have to fetch the no op and try to transform themselves (against a no-op) to catch up to the correct version
  • no-ops are also then broadcast to other subscribers, using unneeded bandwidth and possible transforms on remote clients

It would be nice to (optionally?) skip committing no-ops to the database to avoid the above.

The main issue with this is that clients expect every submitted op to increment the version (which wouldn't be true in this case), so we'd need to add some machinery around telling the client that their op was no-oped and they shouldn't increment the version (maybe we can extend the ack message?).

The lazy way to do it is to return an OP_SUBMIT_REJECTED (or create a new similar error code), but this would only work on invertible types, since non-invertible types would get a hard rollback, and lose any pending ops.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @alecgibson

        Issue actions

          Avoid committing no-ops · Issue #616 · share/sharedb