Adam,
I'm not sure it is identical though it looks to be. I definitely
would replace it as you suggest if only to simplify the code. I just
posted this to give Chris a place to start and hopefully something
towards the answer. I'm sure sure there are not other places that
also need to change.
Thanks for noticing those glitches in the test cases, I was so
thick in it I wouldn't have thought my solution was exposing
something there, I just assumed I was wrong. Can't beat eyeballs
It's a very nice piece of Elang code. I'm enjoying learning it.
Cheers,
Bob
On Jan 8, 2009, at 10:36 PM, Adam Kocoloski (JIRA) wrote:
[ https://issues.apache.org/jira/browse/COUCHDB-196?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=12662235#action_12662235 ]
Adam Kocoloski commented on COUCHDB-196:
----------------------------------------
Hi Bob, thanks for looking into this. I'd argue for replacing that
entire function with couch_view:less_json/2
diff --git a/src/couchdb/couch_db_updater.erl b/src/couchdb/
couch_db_updater.erl
index 049a354..38885f8 100644
--- a/src/couchdb/couch_db_updater.erl
+++ b/src/couchdb/couch_db_updater.erl
@@ -253,13 +253,8 @@ init_db(DbName, Filepath, Fd, Header0) ->
Header = simple_upgrade_record(Header0, #db_header{}),
{ok, SummaryStream} = couch_stream:open
(Header#db_header.summary_stream_state, Fd),
ok = couch_stream:set_min_buffer(SummaryStream, 10000),
- Less =
- fun(A,B) when A==B -> false;
- (nil, _) -> true; % nil - special key sorts before all
- ({}, _) -> false; % {} -> special key sorts after all
- (A, B) -> A < B
- end,
-
+ Less = fun couch_view:less_json/2,
+
{ok, IdBtree} = couch_btree:open
(Header#db_header.fulldocinfo_by_id_btree_state, Fd,
[{split, fun(X) -> btree_by_id_split(X) end},
{join, fun(X,Y) -> btree_by_id_join(X,Y) end},
The DB behavior seems to be the same either way, and the fewer
places we have this collaction algorithm coded up the better. I
looked into the 2 test suite failures that show up as a result of
applying either of these patches. The failure in design docs
occurs because the test suite expects to find the document "_design/
test" in the _all_docs view between "_design%2F" and "_design%
2FZZZ". That expectation is erroneous. I'm not sure why it worked
before.
The second failure occurs in view_include_docs where an _all_docs
view is queried with limit=2&skip=1. In the trunk code _design
docs sort after docs with stringified integers for ids. Your patch
causes the _design docs to sort first, which I believe is the
correct behavior. Again, the test suite's expectation is probably
wrong.
Bug in _all_docs: extra incorrect row returned when ?key= is
specified
---------------------------------------------------------------------
-
Key: COUCHDB-196
URL: https://issues.apache.org/jira/browse/
COUCHDB-196
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Reporter: Jason Davies
Attachments: collation_ids.diff, collation_test.2.diff,
collation_test.diff, couch_db_updater.diff, view_coll.js
I first noticed this when attempting to reverse the order of docs
displayed in Futon, when listing the design docs. When the order
is reversed, non-design docs are displayed.
After digging deeper I discovered that querying _all_docs with
key="Z" can potentially return two rows, with keys "Z" and "a".
I will attach a test case to reproduce this. My locale is set to
en_GB.UTF-8, which could be related to this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
