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 <[email protected]> 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
