[bknr-devel] objects with transient slots

[Hans Hübner]

Hi Kamen,

now I understand what you write and I consider this being a real bug.
Transient slots should be initialized with their default-initargs/initforms,
not with whatever has been specified at object creation time.  Everything
else would be confusing.in general.  I will fix this and commit later on.

Thanks for reporting!
Hans

2007/7/6, Kamen TOMOV <kamen at cybuild.com>:
>
> Hans,
>
> "transient" has some effect because none of the setf-s of slots of
> this kind are in the transaction log, only when suppling data in the
> :initarg they are written there.
>
> In the morning I built something that relies on that behaviour, but
> then realized that it might not be what was intended. That's why I
> mentioned taht this might be a feature ;) Anyway, I'll follow your
> advise - thanks for it!
>
> Perhaps wherever you use transient slots in your applications you setf
> them instead of using :initargs on them and in result they are never
> in the transaction log and things are fine.
>
> Regards,
>
> --
> Камен
>
>
> ----- Original Message -----
> From: Hans Hübner
> Sent: 06 Юли 2007 at 14:50
> Subject: Re: [bknr-devel] objects with transient slots
>
> Kamen,
>
> what you describes looks to me as if the :transient does not have any
> effect
> at all, so the question is what you'd want to use this as a feature for :)
> -  Seriously, what you describe seems to be a bug, as :transient slots
> should never be logged.  In fact, I am depending on this behavior in
> several
> places and I wonder how the store serializes the slots that I'm using.
>
> I'd recommend to use :transient the way that is described in the
> documentation, i.e. assume that such slots will not be restored.  I will
> eventually fix this, but it will propably take a few days until I commit.
>
> -Hans
>
> 2007/7/6, Kamen TOMOV <kamen at cybuild.com>:
> >
> > Hello Hans,
> >
> > Lets define a class:
> >
> > (define-persistent-class a ()
> >   ((s1 :update :transient t)
> >    (s2 :update)))
> >
> > and make an instance of it:
> >
> > (let ((obj (make-object 'a :s1 23 :s2 "ar")))
> > ...
> >
> > and then modify its transient slot:
> >
> > (setf (a-s1 obj) 3)
> >
> > When I stop and start Lisp and do:
> >
> > (make-instance 'mp-store....
> >
> > I get:
> >
> > (slot-value obj 's1)
> > => 23
> > (slot-value obj 's2)
> > => "ar"
> >
> > s1 is transient and one might expect it to be unbound, but it is not,
> > so I wondered if it is a bug or a feature, cause I might decide to use
> > it as a feature :-)
> >
> > However, I guess that if I snapshot and then restore the database the
> > transient slot would be unbound (and that would prevent me from using
> > it as a feature, but I probably need a persistent slot anyway). Am I
> > correct?
> >
> >
> > Regards,
> >
> > --
> > Камен
> >
> >
> > ----- Original Message -----
> > From: Hans Hübner
> > Sent: 06 Юли 2007 at 13:47
> > Subject: Re: [bknr-devel] objects with transient slots
> >
> > Hi Kamen,
> >
> > are you saying that your transient slots are written to the transaction
> > log
> > and snapshot?  This is not the intended behavior.  Can you verify the
> bug
> > by
> > writing some distinctive string to such a slot, snapshot and then look
> in
> > the snapshot file for that string?  Do you see the the value retained
> when
> > restoring or when starting your lisp afresh?
> >
> > Thanks,
> > Hans
> >
> > 2007/7/6, Kamen TOMOV <kamen at cybuild.com>:
> > >
> > > Hi,
> > >
> > > It is said in the datastore-manual:
> > >
> > > "... you can specify that a certain slot is transient, which means
> > > that it will not be snapshotted and that its value can be changed
> > > outside of a transaction."
> > >
> > > In my application the value of a transient slot is specified on object
> > > creation. When reloading the transaction log (server restart) the
> > > transient slot is bound and its value is correct. Is this intended
> > > behaviour or not? How is snapshotting the database different in that
> > > context?
> > >
> > > Thanks in advance,
> > >
> > > --
> > > Kamen
> > > _______________________________________________
> > > bknr-devel mailing list
> > > bknr-devel at common-lisp.net
> > > http://common-lisp.net/cgi-bin/mailman/listinfo/bknr-devel
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bknr-devel/attachments/20070707/c1dcf288/attachment.html>