> In the BDB backend I
> persist data for indexed-btrees so I make that a persistent-metaclass
> and thus shared-initialize always gets called. pm-btree is a unique
> case that wasn't handled.
pm-indexed-btree is of persistent-metaclass, pm-btree is not, for
bootstrapping
reasons.
> My soluti
Ian,
> Please try out the patch that implements this, it should solve the
> special case of pm-btree recreation. It's in the new elephant-1.0
> repository as well as unstable.
>
> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
Just to confirm that this works for me. Many thanks.
There are two problems with calling the full initialization protocol
of an object for all standard classes.
First, you are de-serializing an existing instance not creating a new
one so the semantics of rerunning the initialization procedures when
recreating a serialized object is questionabl
H
Off the top of my head, I'm not sure what's going on. I'll look into
this tomorrow.
Cheers,
Ian
On Jan 3, 2009, at 5:18 PM, Alex Mizrahi wrote:
> HD> Which of stable/unstable do you recommend using?
>
> i think we'll eventually switch to "unstable", so if you're planning
> for the
HD> Which of stable/unstable do you recommend using?
i think we'll eventually switch to "unstable", so if you're planning
for the future, this would be a better option. also the more people
use it, faster we will find all bugs in a new version. OTOH in a short
term perspective "stable" is more te
(I fixed that oids-only problem. It's a tweak I'm adding to improve
join efficiency in the new query planner. Sorry that crept into the
main code base).
I highly recommend you switch to the new repository, elephant-1.0. We
should be able to figure out any problems you have shortly.
Regar
On Sat, 03 Jan 2009, Ian Eslick wrote:
> Do you have the latest version of elephant-unstable as of a day or two
> ago?
Indeed I do. See my reply to Alex.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mai
Changing to use elephant stable gets rid of the problem. Not sure why I
was using unstable - I know I switched back and forth several times when
trying to get something to work when I started working with elephant.
Which of stable/unstable do you recommend using?
BTW, to use unstable I ha
Do you have the latest version of elephant-unstable as of a day or two
ago? The *current-transaction* behavior you mention is suspicious and
I recently made a change to that part of the code which may have
inadvertently made a change that effected the postmodern policy.
Ensure transaction
Looks like that is not one of "usual suspects".. And it is more than
weird -- key-type slot in pm-btree
has initform, so it is unbound only when one explicitly makes it unbound,
and I have no idea where
that could be (in theory, we do not do that at all). To debug this you can
add checks like
(
On Fri, 02 Jan 2009, Alex Mizrahi wrote:
HD> I am having trouble reducing the code to a sensible test case that
HD> exhibits the same behaviour. Any suggestions on how I can track
this
HD> down?
what kind of objects do you put in this btree? i think i've seen a
problem with upgrading
HD> I am having trouble reducing the code to a sensible test case that
HD> exhibits the same behaviour. Any suggestions on how I can track this
HD> down?
what kind of objects do you put in this btree? i think i've seen a problem
with
upgrading btree object type, it might be related.
other qu
Hi,
I have some test code that uses btree's as persistent slot values of a
persistent class, initialised with an :initform (make-btree). Running the
code frequently, but not always, gives the error:
"The slot DB-POSTMODERN::KEY-TYPE is unbound in the object
#."
in DB-POSTMODERN::INITIA
13 matches
Mail list logo
