[elephant-devel] unstable postmodern troubled..

[Ian Eslick]

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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel