[cl-prevalence-devel] restore operation fails with linked objects

[Evan Monroig]

Sven Van Caekenberghe <scaekenberghe at common-lisp.net> writes:

> Evan, Nico,
>
> I was just looking at the test code but Nico was faster, I guess I
> needed more time to get back into cl-prevalence.
> Indeed, my first reaction was to do something like this:
>
> (defun tx-set-person-parent (system person-id parent-id)
>   (let ((person (find-object-with-id system 'person person-id))
>         (parent (find-object-with-id system 'person parent-id)))
>     (setf (parent person) parent)))
>
> (defun make-joe-and-ma-2 ()
>   (let* ((ma (make-person :firstname "Ma" :lastname "Dalton"))
>          (joe (make-person :firstname "Joe" :lastname "Dalton")))
>     (setf *ma-id* (slot-value ma 'id))
>     (setf *joe-id* (slot-value joe 'id))
>     (tx-set-person-parent *test-system* *joe-id* *ma-id*)))
>
> To set the link in a seperate transaction based on id's.

Nico, Sven,

Thanks for your fast answers.  It seems that I asked for the moon :).

I understand that your approach to record only the IDs will work better,
though I see that it can be tedious since you have to replace objects by
their IDs when recording changes on them, and replace IDs by associated
objects when retrieving them from the database.

Actually the example was a little contrived and the slot that I have is
a tree containing any number of persisted objects (that all inherit the
OBJECT-WITH-ID class), but I will try using this approach and see if
that can be done without too much hassle.

> On 13 Mar 2008, at 10:08, Nico de Jager wrote:
>
>> I can duplicate your reported behaviour in LispWorks Pro 5.0.2 for
>> Linux, but I thought this was normal behaviour. When passing a
>> compound object as parameter to a data manipulation/creation
>> transaction function, information is saved in the transaction log to
>> recreate such an object. I suppose code can be added to check for
>> OBJECT-WITH-ID descendants when the transaction log is replayed to
>> just return the same (under EQ) object (instead of reconstructing it)
>> if such an object already exists, but in the general case (i.e.  non
>> OBJECT-WITH-ID objects) there is no way to check for this type of
>> equality and you'll end up with duplicates. Anyone please correct me
>> if I am wrong.

> However, (1) I haven't fully tested this (2) it seems that Evan's test
> code suggest that the problem is not in replaying the transaction log
> but in recovering from the snapshot which is different. I will
> continue looking into this when I have more time today...

(pardon me for changing the order of your writings, I hope that the flow
of ideas is respected this way)

As Nico wrote the behavior I'm having is not necessarily a bug, but
anyway there still is a problem in that recovering from the transaction
log or from the snapshot yields different results.  I think that the
"correct" way to go would be to check for OBJECT-WITH-ID descendants
while making and/or replaying the transaction log.

Thanks again,

Evan