Fork me on GitHub
#onyx
<
2018-09-25
>
xiongtx22:09:51

When creating a sliding window based on elements rather than time, what should be the value of :window/window-key? Doesn't seem like it should be necessary, but the docs say it's required: http://www.onyxplatform.org/docs/cheat-sheet/latest/#window-entry/:window/window-key

Lutz08:09:44

Having considered this, too, I think the problem with window based on a fixed number of elements cannot be done in general. If your task is setup to run on more than one peer, there is no way for these peers to tell how many segments there have been in the current window.

Lutz08:09:01

If you mean sliding window based on some key with real number values rather than timestamps, I cannot see a reason why this should not work. As far as I can tell, this is not supported by onyx. If you really need to make it work, you can consider the hack of mapping your real values to timestamps, while preserving the ordering and translating the respective ranges. Needless to say, this would be bad practice.

xiongtx22:09:59

Also, can the window's trigger pass the window of elements to a downstream task? All the learn-onyx examples just have the state put into an atom. I'm basically trying to replicate a pattern in core.async whereby a partition transducer is used to create windows of elements in a channel, which can then be processed downstream.