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

CardinalityOne not correct for partially-ordered times #76

Open
comnik opened this issue May 9, 2019 · 0 comments
Open

CardinalityOne not correct for partially-ordered times #76

comnik opened this issue May 9, 2019 · 0 comments
Labels
bug Something isn't working

Comments

@comnik
Copy link
Owner

comnik commented May 9, 2019

The state machine powering the CardinalityOne operator currently assumes totally ordered input timestamps, s.t. when processed in time order (i.e. in the order that consolidate will reveal them), all keys end up in the correct state.

In fact, the current implementation is a bit stronger, in that it should still produce correct results on bitemporal inputs, as long as event times increase monotonically per key. This is due to an additional sort by event time after consolidation.
For general partially-ordered inputs this is not safe any longer.

A solution might be to re-implement CardinalityOne as a special kind of arrange. This way we could use the trace handle to lookup the correct last value as of the input time, without having to maintain two traces per attribute.

The existing implementation should get rid of the additional sort and live on as CardinalityOneTotal, or something like that.

@comnik comnik added the bug Something isn't working label May 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant