IE> I don't have a strong opinion about how this should be fixed, but
IE> let's make sure we aren't hacking up the initialization to fix a
IE> fundamental problem with the use of the class hierarchy. It might
IE> make more sense if we make indexed-btrees not inherit from persistent
IE> object
On Jan 9, 2008, at 4:02 AM, Alex Mizrahi wrote:
the problem was actually quite easy -- pm-btree needs to initialize
it's
transient each time it's created or deserialized. it participates
both as
descendant from "persistent" as pm-btree itself, and as persistent-
object in
form of pm-indexe
On Jan 8, 2008 7:33 PM, Alex Mizrahi <[EMAIL PROTECTED]> wrote:
> so i'm thinking about patching this recreation stuff this way:
>
> ;;
> ;; RECREATING A PERSISTENT INSTANCE
> ;;
>
> (defmethod recreate-instance-using-class ((class standard-class) &rest
> initargs &key &allow-other-keys)
> "recre
On Wed, 2008-01-09 at 11:02 +0200, Alex Mizrahi wrote:
> is my English that poor so nobody understand me??).
>
No, your English is great. I think there were so many emails yesterday
that it was hard to know exactly whom to respond to.
Thanks, this is great work; I'm sorry I couldn't figure it o
the problem was actually quite easy -- pm-btree needs to initialize it's
transient each time it's created or deserialized. it participates both as
descendant from "persistent" as pm-btree itself, and as persistent-object in
form of pm-indexed-btree.
(so pm-btree is quite a good test for a new s
