TimelyDataflow / TimelyDataflow/differential-dataflow
Several implicit commutativity assumptions
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 3k
- Forks
- 211
- Avg merge
- 10h 42m
- Merged PRs (30d)
- 34
Description
trace::consolidate_by and ord batch merging both implicitly assume commutativity of the difference type, because they accumulate rhs += lhs, rather than the other way round (see here, here, and here).
The motivation here was a trace with HashMap differences, that did not accumulate correctly.
I will take a stab at patching these, but wanted to see whether there was a reason for doing them in reverse.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read the accumulation sites in src/trace/mod.rs around line 501 and src/trace/implementations/ord.rs around lines 112 and 394. Check how rhs += lhs behaves for non-commutative difference types such as the mentioned HashMap differences, then verify that the affected trace consolidation and ord batch merging accumulate correctly without relying on commutativity.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- distributed-systems
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 38/100