TimelyDataflow / TimelyDataflow/differential-dataflow
enter_at is specialized to Product scopes
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 3k
- Forks
- 211
- Avg merge
- 10h 42m
- Merged PRs (30d)
- 34
Description
I might be missing something, but going directly from a top-level scope into an AltNeu sub-scope is a bit unergonomic at the moment, because enter_at assumes a Product timestamp. I'm haven't had the time to check where this specialisation is enforced.
In any case, it's not a big deal, I'm working around this by simply breaking out all of the stuff that enter_at is doing under the hood.
scope.scoped::<AltNeu<S::Timestamp>, _, _>("AltNeu", |subgraph| {
let proposals = propose
.as_collection(|e: &Value, _v| e.clone())
.inner
.enter(subgraph)
.delay(move |_datum, t| AltNeu { neu: true, ..t.clone() })
.map(move |(data, t, diff)| {
let new_time = AltNeu { time: t.clone(), neu: true }
(data, new_time, diff)
});
});
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
Start by locating the enter_at implementation and where it assumes a Product timestamp; compare it with the scoped and enter paths shown in the issue. The work is done when a top-level scope can enter an AltNeu sub-scope without reimplementing the underlying operations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- stream-processing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100