Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Serialization warnings
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: <4FDB00C0.2020204@maniatis.org>
Date: Fri, 15 Jun 2012 12:42:05 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <595E9D02-0C3D-437B-96E3-F3A0B91B7077@objectstyle.org>
References: 
 <CAA-upzoaWC38DJKVp0bCzKWEk=FmLC+0i1fByX4rk7GbVNEm8w@mail.gmail.com>
 <CAM1yOjYWYG3Z67c2Q-7shRF3BKmx1E4251xgQ3OTVgEmZ2mRsg@mail.gmail.com>
 <CAA-upzohsqDzV8wDo5WSb7MCjCYeR+6rVnV=kMcEsHUmWOYD7g@mail.gmail.com>
 <CAM1yOjacpHuSE-Kk5ppmxs604LG_zsJgBz7Pg18Ru7Odnq3BXA@mail.gmail.com>
 <CAA-upzoRdUP2N71s2vHEnrqmK_NHGvD57nEvKaytXFbWwqtOjw@mail.gmail.com>
 <CAM1yOjaSJ8uT6wtbHe_pEz9uSG_LCby117mZiL5yUxHQ9WBYeA@mail.gmail.com>
 <CAA-upzqQsV-x-Z-Rj=0B-EX-XVTt+B1muqLbT1U5xx0sKifX3A@mail.gmail.com>
 <CAM1yOjat3CrM5ZuJWJ1j8YtgBvrGNrmQo7jBqZvj34-_d9iyxQ@mail.gmail.com>
 <C6479E749D884341B03A760750BB4D8E04E7D60C@eex1.hennig.local>
 <4FDAFCFF.9060808@maniatis.org>
 <AAAABA30-14E8-4FBC-B8DF-5531B47B4D09@objectstyle.org>
 <4FDB00C0.2020204@maniatis.org>
To: dev@cayenne.apache.org

See my earlier message. IMO serialVersionUID of the server superclass is =
immutable as it doesn't declare any properties. For ROP client =
serialVersionUID will depend on the model changes, but only on those =
that change java signature of the ivars (e.g. changing DbAttribute =
LENGTH should not result in serialVersionUID change; renaming =
ObjAttribute should). And I think this should be handled automatically =
(why not?)

The scope of "invalidation" is really just previously serialized objects =
stored somewhere in a binary form. And I guess those should be =
invalidated when the ROP object format changes, right?

Andrus


On Jun 15, 2012, at 12:30 PM, Aristedes Maniatis wrote:

> Yes, but this really only has an effect if you serialise the Cayenne =
entities across a cluster, or to a database (where they are read by a =
new version of the application which you launch). In that case do we =
want to automatically throw a serialisation exception for the user when =
the the change in the Cayenne model was unimportant to the operation of =
the application?
>=20
> Isn't this something which the developer should change by hand in the =
subclass and not have Cayenne automatically invalidate every object in =
the _superclass just because there was some (possibly insignificant) =
change in the model?
>=20
> Or am I missing the use cases of this feature?Are we actually helping?
>=20
>=20
> Ari
>=20
>=20
> On 15/06/12 7:21pm, Andrus Adamchik wrote:
>> Serialized HttpSessions is one common case. This is on in Tomcat by =
default, so every time you restart the server, Tomcat goes through =
serialization cycle.
>>=20
>> Andrus
>>=20
>> On Jun 15, 2012, at 12:14 PM, Aristedes Maniatis wrote:
>>=20
>>> On 15/06/12 6:34pm, Durchholz, Joachim wrote:
>>>> Don't take this as an expert opinion, but since subclasses contain =
all
>>>> member fields of the superclass, I'd expect that a subclass needs =
to
>>>> have a changed SerialVersionUUID if the superclass changes.
>>>>=20
>>>> Testing this aspect might be in order.
>>>=20
>>> My question would be: test what? In the real world are =
SerialVersionUUID particularly useful for Cayenne entities? With Cayenne =
ROP, I've never seen any code in Hessian which pays any attention to the =
version. Is this more useful with a cluster of application servers and =
different instances running different versions of the code? Are there =
are specific use cases where Cayenne entities would be involved?
>>>=20
>>>=20
>>> Ari
>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>>>=20
>>>=20
>>>=20
>>=20
>=20
> --=20
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>=20
>=20
>=20