> -----Original Message-----
> From: Craig Miskell [mailto:cmiskel..lbatross.co.nz]
> Sent: Wednesday, February 19, 2003 12:55 PM
> To: cayenne-use..bjectstyle.org
> Subject: RE: Hollow state
>
>
>
> On Thu, 2003-02-20 at 07:33, Andrus Adamchik wrote:
> > Serialization works the other way around in Cayenne - DataContext
> > serializes and deserializes its objects. Making context transient
> > allows to avoid double serialization (Craig Miskell, who
> implemented
> > this code may, correct me if I am wrong).
> This is correct, although not to avoid double serialization.
> To quote from DataContext (readObject):
>
> // CayenneDataObjects have a transient datacontext
> // because at deserialize time the datacontext may
> need to be different
> // than the one at serialize time (for programmer
> defined reasons).
> // So, when a dataobject is resurrected because it's
> datacontext was
> // serialized, it will then set the objects
> datacontext to the correctone
> // If deser'd "otherwise", it will not have a
> datacontext (good)
>
> This all stems from the fact that simply serializing a
> DataObject should not (and from the user perspective would be
> rather surprising if) the DataContext, and *all* the other
> DataObjects currently registered in that DataContext, were
> serialized too.
>
> However, this situation does kind of show a flaw in that
> logic (well, the logic is sound but it doesn't account for
> all potential uses).
>
> David: while your solution (refetching etc.) will work, I
> don't think it's quite the best generic solution, and I get
> the feeling I'm going to have to do some serious thinking
> about how to facilitate this sort of situation.
>
I agree.
> Off the top of my head, however, we might do something
> similar to EOF, where there is a "current DataContext"
> variable (probably per thread), and the value is used as the
> DataContext when deserializing CayenneDataObject's. When
> deserializing a DataContext, it just sets that variable to
> itself and deserializes it's objects (they'll pick it up).
> Then we just need some hook into the Tapestry property
> deserialization to set the variable to the relevant
> DataContext for the Visit (typical usage at least).
>
> Any thoughts on whether this will actually fix the problem
> (does such a hook exist in Tapestry that could be used?)
>
Well, there is a Tapestry extension (net.sf.tapestry.value-persister) to
change the DefaultValuePersister class.
Regards
David
> Craig
>
>
>
>
This archive was generated by hypermail 2.0.0 : Wed Feb 19 2003 - 14:32:54 EST