> I'm sure there's a good explanation for this. The explanation is that if an object has a serializable reference to the context, serializing a single object would also serialize the context ... and all the objects in the context. If unsuspected developers serialize N individual objects at once, they will be creating N huge copies of the context and its contents.
There's unfortunately no clean solution for an "unmanaged" (de)serialization of the context-attached auto-expanding object graph. The one we have right now, that requires the context to be the serialization "root", seems like the best choice out of the available options. Andrus > On Feb 26, 2019, at 12:59 PM, Lon Varscsak <lon.varsc...@gmail.com> wrote: > > So reviving this topic (which is different than the one I just posted > separately), if I archive the DataContext myself along with the object, all > works as I'd expect (objectContext is not null and I get values back from > the object). I guess I was just surprised that in the case of a Web > application, where the serialization of an object is outside my knowledge > (like when a framework might archive pages to save on memory) that I would > also have to remember to have a reference to (so it would also serialize) > the DataContext. It happens that I almost always do, but sometimes one > might fetch some stuff with a context that they don't have a reference to > and would get this issue. > > I'm sure there's a good explanation for this. > > On Thu, Feb 7, 2019 at 6:17 AM Nikita Timofeev <ntimof...@objectstyle.com> > wrote: > >> Hi Lon, >> >> The behavior you described in field-based objects seems normal >> according to Cayenne own test case (see [1] for master branch and [2] >> for 4.0 branch). >> It should be like this in map-based objects too (i.e. no context and >> no values inside). It is supposed that you attach object to context >> manually after deserialization. >> So unless you had some custom logic in map-based objects case, I >> really don't know what is happening. >> >> Maybe you can share your test case? >> >> [1] >> https://github.com/apache/cayenne/blob/master/cayenne-server/src/test/java/org/apache/cayenne/DataObjectSerializationIT.java#L129 >> [2] >> https://github.com/apache/cayenne/blob/STABLE-4.0/cayenne-server/src/test/java/org/apache/cayenne/DataObjectSerializationIT.java#L129 >> >> On Thu, Feb 7, 2019 at 2:07 AM Lon Varscsak <lon.varsc...@gmail.com> >> wrote: >>> >>> Hey all, >>> >>> Recently I switched to 4.1's field based data objects (I've been using >>> 4/4.1 for a while, but using the Map based objects) and I ran into an >>> issue. It appears that when using this type of object, the >>> de-serialization results in an object that is not usable. It results in >> a >>> HOLLOW object that returns null for all of its values. This object is >> in a >>> COMMITTED state to start (no changes), so it really shouldn't be doing >>> anything special with serialization, but something is amiss. >>> >>> To set the stage: So the object is called Site, it's PK is called siteId. >>> I fetch an object, I then serialize that object (normally the web >> framework >>> would choose when to, but I've create some test code to verify this), I >>> then deserialize the object. Now when I call get*AnyAttribute*() on the >>> deserialized Site object, they all return null and the object is HOLLOW. >>> In the Map based template, the object is still hollow, but all of the >>> properties will return a value. >>> >>> Something else that really surprised me (just because of how long I've >> been >>> working with this code) is that the deserialized object in both cases no >>> longer have an object context. Not sure how I haven't encountered a >>> problem with that before. >>> >>> Any thoughts? >>> >>> -Lon >> >> >> >> -- >> Best regards, >> Nikita Timofeev >>
