Thanks, Andrus, for this example. I wouldn't have been able to come
up with it without a lot of pain and suffering first.
However, in the case where the DataContext is no longer the same,
won't I lose all new and modified objects?
I don't want to serialize the entire DataContext and ObjectStore. I
only want to preserve a few specific items, and almost always those
objects are in a modified or new state.
Yeah, I know this is a reversal of my previous "rule" that a
request/response shouldn't leave any new/modified/deleted objects
around between requests, but I'm not sure if I'm going to be able to
get around this particular limitation.
-Mike
On 9/26/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
>
> On Sep 26, 2005, at 6:03 PM, Andrus Adamchik wrote:
> > My solution for that (I haven't tried it yet) was to rely on thread
> > DataContext during de-serialization and substitute deserialized
> > object clone with an object from that DataContext using
> > 'readResolve'. This would minimize the serialized footprint and
> > maintain uniquing.
>
> Ok, I figured I'd test my idea - see an attachment to CAY-298. In
> short - it works (with my today's TempObjectId CVS fix). Wedge
> DataObject superclass can be as simple as this:
>
>
> public class WedgeDataObject extends CayenneDataObject {
>
> /**
> * Substitute self with an object registered in thread
> DataContext with the same ID.
> */
> protected Object readResolve() throws ObjectStreamException {
>
> DataContext context;
>
> try {
> context = DataContext.getThreadDataContext();
> }
> catch (IllegalStateException e) {
> throw new NotActiveException("Can't deserialize object
> for id '"
> + getObjectId()
> + "' - no DataContext bound to thread.");
> }
>
> return context.registeredObject(getObjectId());
> }
> }
>
> Andrus
>
This archive was generated by hypermail 2.0.0 : Tue Sep 27 2005 - 12:48:50 EDT