Expected Behavior
During work on #560 it was found that there are bug in mrview's seq btree leading to inconsistent behaviour on query with since parameter.
It is expected that when querying view_changes_since we should get changes feed starting from next update sequence than provided at since.
Current Behavior
Response of couch_mrview:view_changes_since/7 either include or exclude entry for since update sequence, depending on a view's key data type.
Possible Solution
The issue here is that seq_btree using tuples{UpdSeq, ViewKey} as the keys and ViewKey can be any mapped from JSON data type: binary, integer or boolean. We are using erlang native collision to find first key to start from, so we can't construct consistent low limit key.
We need to specify custom less function on seq_btree creation and normalize keys in it.
Steps to Reproduce (for bugs)
Since http end-point /{db}/_design/{ddoc}/_view_changes not exposed at the moment it's a bit hard to reproduce without changing existing changes_since_test_ test suite to create view with integer keys instead of binaries.
Context
It's a low priority issue, the function in question not exposed to any interface.
Expected Behavior
During work on #560 it was found that there are bug in mrview's seq btree leading to inconsistent behaviour on query with
sinceparameter.It is expected that when querying
view_changes_sincewe should get changes feed starting from next update sequence than provided atsince.Current Behavior
Response of
couch_mrview:view_changes_since/7either include or exclude entry forsinceupdate sequence, depending on a view's key data type.Possible Solution
The issue here is that
seq_btreeusing tuples{UpdSeq, ViewKey}as the keys andViewKeycan be any mapped from JSON data type: binary, integer or boolean. We are using erlang native collision to find first key to start from, so we can't construct consistent low limit key.We need to specify custom
lessfunction on seq_btree creation and normalize keys in it.Steps to Reproduce (for bugs)
Since http end-point
/{db}/_design/{ddoc}/_view_changesnot exposed at the moment it's a bit hard to reproduce without changing existingchanges_since_test_ testsuite to create view with integer keys instead of binaries.Context
It's a low priority issue, the function in question not exposed to any interface.