Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changeset Inverses Brain Dump Doc #11484

Merged
merged 23 commits into from Aug 18, 2022

Conversation

yann-achard-MS
Copy link
Contributor

Adds a document containing a brain dump on inverse changes and undo.

@yann-achard-MS yann-achard-MS requested a review from a team as a code owner August 10, 2022 00:29
@github-actions github-actions bot added area: dds Issues related to distributed data structures base: main PRs targeted against main branch labels Aug 10, 2022
@yann-achard-MS
Copy link
Contributor Author

TODOs:

  • Mention how rebasing over inverses works differently in undo vs. rebase cases
  • Add "Blob + Changes" as a way of describing repair data

packages/dds/tree/docs/wip/inverse-changes/README.md Outdated Show resolved Hide resolved
packages/dds/tree/docs/wip/inverse-changes/README.md Outdated Show resolved Hide resolved
packages/dds/tree/docs/wip/inverse-changes/README.md Outdated Show resolved Hide resolved
peers need to have access to the following as far back as the collaboration window extends:
* Changes and their associated repair data

#### Data Communication Needs
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this section should indicate that it is be possible to implement a design where peers sometimes or always have the results of these queries cached locally, especially in the case where there is a bound on how old the target of an undo can be. I think we would like to support systems which want to fully process all incoming changes synchronously.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you thinking of an approach where the changeset sent by the issuing client would not contain the repair data but instead contain some characterization of it, which peers would then be able to fill out? If so, do think of that as something different than what is described in the "Late Repair Data Concretization" section?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the guaranteed synchronous design, it could be what's described in Late Repair Data Concretization. I don't have a specific design proposal, but I think it would be nice if (assuming we're not sending all repair data inline) we always sent the references to the repair information in a format that makes it easy both to craft queries to a service and to find the information locally if it exists. Just sending a URL to a blob with all the repair data, for example, would not meet the criteria I'm proposing, because peers which had the relevant repair data available locally would probably not be able to convert that URL into a query on their local data.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a "Abstract Repair Data Description" section here. I agree it's good to call out here. Documentation should favor clarity at the risk of redundancy.

packages/dds/tree/docs/wip/inverse-changes/README.md Outdated Show resolved Hide resolved
packages/dds/tree/docs/wip/inverse-changes/README.md Outdated Show resolved Hide resolved
packages/dds/tree/docs/wip/inverse-changes/README.md Outdated Show resolved Hide resolved
packages/dds/tree/docs/wip/inverse-changes/README.md Outdated Show resolved Hide resolved
yann-achard-MS and others added 2 commits August 15, 2022 17:19
Co-authored-by: alex-pardes <105307164+alex-pardes@users.noreply.github.com>
@yann-achard-MS yann-achard-MS merged commit fe10534 into microsoft:main Aug 18, 2022
@github-actions
Copy link
Contributor

This commit is queued for merging with the next branch! Please ignore this PR for now. Contact @microsoft/fluid-cr-infra for help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: dds Issues related to distributed data structures base: main PRs targeted against main branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants