Actually btree-index also needs to be persistent-metaclass because of
its use of slot values. However, dup-btree does not if that makes
your life easier. I pushed a patch to remove that from bdb-
collections. All tests pass under SBCL / Linux / BDB (my new primary
dev platform).
Ian
On Jun 1, 2008, at 9:28 PM, Ian Eslick wrote:
Sounds like there is an issue with schema coherence (the class
object cache out of sync with the db in some way? I had some of
these tuning the BDB implementation). I'd be happy to look at the
patches.
I think the semantics of cursor-delete are the current 'element'.
If I can do cursor-next to get to the next element of a duplicate
set, I wouldn't expect it to have been deleted when I deleted the
last one - so just the specific key-value pair that would be
returned by cursor-current.
The indexed-btree is the only class that requires it due to the
indices slot. It would take quite a bit of work to handle all the
issues that persistent-metaclass takes care of. However, the btree,
dup-btree, and btree-index don't need it. I'll pull it out of the
BDB implementation and test it.
Ian
On Jun 1, 2008, at 3:48 PM, Alex Mizrahi wrote:
i can't say i'm completely stuck with it,
but i'm getting pretty weird errors -- it's
different if i run it first time or second time
(on second time there are more errors), and, if i run
whole test suite i get:
SIMPLE-SLOT-ASSOC-SETUP []:
Unexpected Error: #<SIMPLE-ERROR {C350169}>
There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION ELEPHANT::SCHEMA-ID (1)>
when called with arguments
(NIL)...
but when i run test individually, it works:
ELE-TESTS> (do-test-spec 'SIMPLE-SLOT-ASSOC-SETUP)
.
Did 1 check.
Pass: 1 (100%)
Skip: 0 ( 0%)
Fail: 0 ( 0%)
NIL
so i thought maybe i'll post half-backed patches and someone
could help debugging it -- with such weird bugs more eyeballs
is always better.
also, few questions to Ian:
* cursor-delete on dup-btree -- should it delete only current
pair or all pairs on some key?
* why dup-btree has persistent-metaclass? (and so do some other btree
flavours)
if it don't use persistent-metaclass, drop-pobject fails for
dup-btree, but other than that i can't see any reasons..
why should dup-btree be different from normal btree?
this might introduce some bloat, so if drop-pobject is the only
reason, it might be easier to just add method specialization
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
