cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Property class and Serialization
Date Wed, 15 May 2019 06:16:36 GMT
TL;DR: Serialization is a non-trivial contract to support, so we don't make things serializable
unless absolutely necessary. 

In the early days of Cayenne we wanted almost everything to be serializable:

1. Contexts and objects (and everything they rely upon) was serializable for convenience,
as most frameworks of the day would rely on sessions, and those could be clustered / persisted.
This wasn't particularly efficient, as each session could drag  around tens of megabytes of
data or more, but it was unavoidable. It was also impossible to make transparent, so you needed
an explicit step on deserialization reattaching objects to the stack.

2. Metadata (DataMap, etc) and Query objects were made Serializable because of Cayenne ROP.

As the things have evolved in the industry in the direction of stateless services (and ROP
having a good chance to get deprecated soon), my hope is that we can gradually do away with
serializability constraints through the stack (perhaps keeping #1 as an option). So most new
APIs are not serializable by default.

With the Property class, it won't be the end of the world if we make it Serializable, but
it feels like under "normal" conditions this should not be needed. An object holding it may
actually implement its own read/writeObject to save it as a String. Hope that's not too much


> On May 15, 2019, at 3:36 AM, Lon Varscsak <> wrote:
> Not really.  I do understand transient, but I'd have to store other data to
> be able to recreate the Property when needed.  It just seems like an
> unnecessary step unless there's a reason that Propertys aren't serializable.
> -Lon
> On Tue, May 14, 2019 at 3:59 PM John Huss <> wrote:
>> Does this help?
>> On Tue, May 14, 2019 at 5:20 PM Lon Varscsak <>
>> wrote:
>>> Any reason we can't have Property be Serializable?  I have situations
>> where
>>> I will keep references to properties in a web page (like for dynamic
>>> columns) and my framework serializes those things (or errors out if it's
>>> not serializable).  I originally solved this with having my own Subclass
>> be
>>> Serializable, but now with protected constructors I'm getting errors.
>>> Thoughts?
>>> -Lon

View raw message