One hole in with-transaction, at least for BDB, has been the fact that
any non-local exit causes a transaction to fail. I've now added a
quick hack that catches all conditions and calls an optional :inhibit-
rollback-fn to see if the condition is a normal part of success - if
so, it is re-s
I apologize for replying to my own reply, but in the process of
recreating this from a fresh bdb, i noticed another artifact of the
error condition. Before the unbound slot errors begin to appear, I get
an ELEPHANT:ELEPHANT-TYPE-DESERIALIZATION-ERROR; just once, and then
the unbound slot erro
I was finally able to recreate this in the repl (as opposed to seeing it
in my error logs), so here is a trace:
The slot DB-BDB::INDICES-CACHE is unbound in the object
#.
[Condition of type UNBOUND-SLOT]
Backtrace:
0: ((SB-PCL::FAST-METHOD SLOT-UNBOUND (T T T)) # # #
# DB-BDB::INDICES-C
I am seeing an intermittent error with 1.0 alpha when trying to write to
an indexed btree (using BerkeleyDB 4.7 as provided by Ubuntu's package
repositories):
The slot DB-BDB::INDICES-CACHE is unbound in the object
#
Within the same thread, sometimes this happens and sometimes I am able
to
Anyone interested in doing a code review of the GC? I think i'm
done. It really helps to have a second (or third) pair of eyes when
dealing with concurrency issues.
Ian
___
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lis
Re-evaluating the class definition is sufficient. The database
automatically synchronizes to the current class definition.
Beware!
When you remove a slot from the definition, or even rename it, the
values associated with the slot are dropped from all instances (unless
you've enabled lazy s
