return value of IObservableCache SortAndBind #958
Replies: 2 comments 1 reply
-
My intuition says "no, they should not be ordered". The functional goal of the operator, to me, is only to subscribe to and consume changesets, to apply them to a target, not to actually perform transformations. Me personally, I would have clarified this fact by having the operator return Looking at the code, what the operator is doing is effectively... return source.Do(...); So, yeah, it's quite literally just passing through the changes, for convenience. However. I ALSO note that the code, internally is ACTUALLY doing the following... _sorted = source.Do(...);
...
return _sorted; So, it's entirely possible that @RolandPheasant intended to have the downstream be sorted. I suspect that's not the case, because the big point of combining If @RolandPheasant can confirm, we can definitely update documentation to clarify that the downstream is a passthrough for convenience only. |
Beta Was this translation helpful? Give feedback.
-
Regarding the cache side of DD, sorting was only ever intended for binding and virtualization. The reason is due to the limitation of storing the sate in a dictionary which has no index awareness. I recall originally, I tried to store sorted state in a sorted dictionary, which failed. Then I tried to use an internal container which held an index. This also failed, and I realized it was pointless trying to keep the state sorted across downstream operators would exponentially complicate an already difficult problem domain. |
Beta Was this translation helpful? Give feedback.
-
Should the
IObservable<IChangeSet<TObject, TKey>>
returned by theIObservableCache SortAndBind
be in sort order?I assumed it would be, but calling
QueryWhenChanged()
on the returned observable produces an unordered list.Beta Was this translation helpful? Give feedback.
All reactions