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
SR> All the methods defined are defined on persistent-object and it
SR> appears that persistent-object
SR> is not on pm-indexed-btree's class-precedence-list which could cause
SR> various amounts of havoc.
doesn't this function do so:
(defmethod shared-initialize :around ((class persistent-me
On Jan 8, 2008 8:35 PM, Sean Ross <[EMAIL PROTECTED]> wrote:
> On a different note, It may be worth requiring that
> perstistent-metaclasses have persistent-object on their class-precedence-list
> although that is bound to have implications that I haven't thought of.
Sorry all, please ignore tha
On Jan 8, 2008 7:38 PM, Robert L. Read <[EMAIL PROTECTED]> wrote:
> Thank you very much, Sean. I suggest you work with Henrik and Alex and
> I on this as well (possibly off-line, outside of this forum.)
Thanks, I'll try and put together an initial proposal for Henrik, Alex
and I to start with.
>
persistent is simply a base class that maintains an OID which is
initialized using the :from-oid (so it picks up the oid during
deserialization by default)
persistent-object is the superclass for all objects for which we are
allowing the persistent slot access protocol
persistent-collecti
Thank you very much, Sean. I suggest you work with Henrik and Alex and
I on this as well (possibly off-line, outside of this forum.)
In case it helps, here is what I tried to do, and what I think I
discovered. Please forgive me if I am inconsistent; I clearly have been
confused on some of these
SR> I'm sorry to hear that my patch caused so many issues with postmodern
SR> and I'm quite keen to investigate the cause of this. I'll be
SR> installing setting up the postmodern backend and seeing if I can track
SR> down the causes of these problems.
looks like it's related to some deep weird
SR> I'm sorry to hear that my patch caused so many issues with postmodern
SR> and I'm quite keen to investigate the cause of this. I'll be
SR> installing setting up the postmodern backend and seeing if I can track
SR> down the causes of these problems.
looks like it's related to some deep weir
Hi all,
I'm sorry to hear that my patch caused so many issues with postmodern
and I'm quite keen to investigate the cause of this. I'll be
installing setting up the postmodern backend and seeing if I can track
down the causes of these problems.
As to where to go from here I do agree with robert o
i thought people might be doing all sorts of funny stuff in their
initialize-instances -- additional initialization unrelated to
instance
slots, validation, writing to logs etc.
and they can be surprised that once they make class elephant-
persistent and
it's loaded from DB, their stuff is n
IE>>> our learning. My guess is that getting all this right can best be
IE>>> accomplished by rationally designing all the functionality from
IE>>> scratch, and rewrite the persistence protocol as necessary to
IE>>> accommodate the new design.
??>>
??>> the way it was working before "the pat
On Jan 8, 2008, at 11:08 AM, Alex Mizrahi wrote:
IE> our learning. My guess is that getting all this right can best be
IE> accomplished by rationally designing all the functionality from
IE> scratch, and rewrite the persistence protocol as necessary to
IE> accommodate the new design.
the way
IE> our learning. My guess is that getting all this right can best be
IE> accomplished by rationally designing all the functionality from
IE> scratch, and rewrite the persistence protocol as necessary to
IE> accommodate the new design.
the way it was working before "the patches" seemed to be
13 matches
Mail list logo
