So I had a look at it myself and it turned out to be much easier than I
had expected, which is what kept me from trying in the first place.
The following method in src/db-bdb/bdb-collections.lisp is the culprit:
(defmethod cursor-prev ((cursor bdb-cursor))
(if (cursor-initialized-p cursor)
(let ((sc (get-con (cursor-btree cursor))))
(with-buffer-streams (key-buf value-buf)
(multiple-value-bind (key val)
(db-cursor-move-buffered (cursor-handle cursor)
key-buf value-buf :prev t)
(if (and key (= (buffer-read-oid key) (cursor-oid cursor)))
(values t (deserialize key sc)
(deserialize val sc))
(setf (cursor-initialized-p cursor) nil))))
(cursor-last cursor))))
That "cursor-last" call at the end looks very suspicious, and indeed
removing it solves the problem. But I don't know where it belongs or if
it can be safely removed. Any ideas?
Cheers,
Chris Laux
Chris Laux wrote:
> Hi again,
>
> I seem to have stumbled across another bug: the from-end argument
> doesn't seem to be working, map-btree always calls with the same
> (presumably last) entry when it is set.
>
> (defun test-btree-from-end (btree from-end)
> (let (acc
> (n 0))
> (map-btree #'(lambda (k v)
> (push (list k v) acc)
> (when (= (incf n) 4)
> (return-from test-btree-from-end acc)))
> btree :from-end from-end)))
>
>> (test-btree-from-end ** nil)
> ((3398012969 #<MESSAGE oid:227324>) (3398012898 #<MESSAGE oid:226751>)
> (3398012815 #<MESSAGE oid:226044>) (3398012772 #<MESSAGE oid:225621>))
>
>> (test-btree-from-end *** t)
> ((3398231130 #<MESSAGE oid:552110>) (3398231130 #<MESSAGE oid:552110>)
> (3398231130 #<MESSAGE oid:552110>) (3398231130 #<MESSAGE oid:552110>))
>
> My setup is BerkeleyDB 4.5.20 with Elephant 0.9.0 with SBCL 1.0.4 on
> Linux/x86-64.
>
> Thanks,
>
> Chris Laux
>
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
