renaming fields in serialised objects

Thread view:

Roedy Green - 02 Jul 2005 15:32 GMT

If I rename a field in a serialised object, e.g fileName to filename,
is there some sample code somewhere so that I can still read the old
version objects?

I don't know when I read a file whether they have been converted the
new name.

Signature

Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Reply to this Message

Stefan Schulz - 03 Jul 2005 01:13 GMT

> is there some sample code somewhere so that I can still read the old
> version objects?
>
> I don't know when I read a file whether they have been converted the
> new name.

AFAIK this is one of the reasons why serialization should not be used as
persistent storage. There is no easy way to do this as far as i know,
except for almost implementing the serialization protocol again in your
readObject, and changing this one name.

Signature

You can't run away forever,
But there's nothing wrong with getting a good head start.
--- Jim Steinman, "Rock and Roll Dreams Come Through"

Reply to this Message

Joan - 03 Jul 2005 02:21 GMT

> If I rename a field in a serialised object, e.g fileName to filename,
> is there some sample code somewhere so that I can still read the old
> version objects?

I read about this somewhere, but forget the details. Short answer
is that you can. It has to do with the serialver command and the
long serialVersionUID
that it produces.

> I don't know when I read a file whether they have been converted the
> new name.
[quoted text clipped - 6 lines]
> Canadian Mind Products, Roedy Green.
> See http://mindprod.com/iraq.html photos of Bush's war crimes

Reply to this Message

Tom Dyess - 03 Jul 2005 04:02 GMT

>> If I rename a field in a serialised object, e.g fileName to filename,
>> is there some sample code somewhere so that I can still read the old
[quoted text clipped - 15 lines]
>> Canadian Mind Products, Roedy Green.
>> See http://mindprod.com/iraq.html photos of Bush's war crimes

Yes, I was reading up on this as well. AFAIK, the long serialVersionUID is a
unique identifier for the class structure. This is similar to a GUID for a
com object and is used for versioning. If the serialVersionUID is different
from when the obejct was persisted, then the object is no longer compatable
with the data. Conversely, if your serialVersionUID is the same, Java will
attempt to load the persisted object. I'm not sure if the case difference
would render the object unreadable. If you don't explicitely create a
serialVersionUID, Java will create one on the fly based on classname and
structure using reflection.

Here is some more info:

http://www.codecompile.com/CodeCompile/webportal?aid=sr&id=11318
http://www.codecompile.com/CodeCompile/webportal?aid=sr&id=11818

Signature

Tom Dyess
OraclePower.com

Reply to this Message

Roedy Green - 04 Jul 2005 00:58 GMT

>If you don't explicitely create a
>serialVersionUID, Java will create one on the fly based on classname and
>structure using reflection.

That one is very fragile IIRC. It seems that even adding methods
nothing to do with the data fields changes the generated number.
Every time you compile your serialised objects stop working.

Signature

Reply to this Message

Roedy Green - 04 Jul 2005 00:57 GMT

>I read about this somewhere, but forget the details. Short answer
>is that you can. It has to do with the serialver command and the
>long serialVersionUID
>that it produces.

I discovered to complicate this that not only is each serialisable
base class supposed to have a id version number, but every individual
subclass as well. I guess the idea is you can rescue the base class
info even if you can't rescue the modified subclass.

I guess the way you do it is the way you would in the old cobol days.

You have the old record layout and the new and you write a utility
that does a move corresponding (faked in java with a utility)
to copy the fields across. You write one of these to convert from v1
to v2, v2 to v3 etc. When you open a file you read the first record
that tells the versionlayout of the file, then apply the appropriate
updater before continuing processing. I worked with a scheme like
this in C for educational software so end users could restore old
datafile backups safely.

Some how though you have to have the same class name used for both old
and new code. I guess you implement an interface on both and load
them with separate class loaders??

This is something than needs automation.

Signature

Reply to this Message

renaming fields in serialised objects

Free Magazines