-
Notifications
You must be signed in to change notification settings - Fork 1k
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
MRView's seq btree needs custom sorter function. #592
Comments
Hi @eiri {"error":"conflict","reason":"Document update conflict."} This works fine if I'm not including document revision in the request for the case when I "undelete" the doc. So, the actual logic still works and I see all the corresponding revisions via |
@AlexanderKaraberov Ah, this happened before of my time, so it took a bit of digging through the old commits to see what's going on here. Yes, this is an intentional change and it was done to address this bug. Short version is that the previous version of To address that This is all a bit esoteric, so I hope it makes sense to you. |
After discussion dev@ mail list we decided to just remove this implementation of view's changes and redoing it later from a scratch. |
* Fix spelling/typo mistake in /_up endpoint description * Bump version number to 3.1.1 (apache#592) * Jenkins: do not alwaysPull true Co-authored-by: Jonathan Hall <[email protected]>
* Bump version number to 3.1.1 (apache#592) * Fix spelling/typo mistake in /_up endpoint description * Document pagination API * Address problems identified durring review * Fix typo * Fix build failures Co-authored-by: Joan Touzet <[email protected]> Co-authored-by: Jonathan Hall <[email protected]>
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 atsince
.Current Behavior
Response of
couch_mrview:view_changes_since/7
either include or exclude entry forsince
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 andViewKey
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 existingchanges_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.
The text was updated successfully, but these errors were encountered: