When deserialization fails, default instead of null value should be provided

[tomas-knap]

Suppose that user:

1. Serializes configuration for DPU template A
2. Adjusts the DPU configuration class for DPU template A, loads it to odcs
3. Tries to deserialize the previously stored configuration (with the previous version of the config class)
4. As a result, all fields except of the new one should be deserialized properly. The new field which was not available in the previous configuration version is set to null. Why the default value is not used for such attribute?

Better behaviour: When there is an error when deserializing certain attribute, instead of using null and calling onDeserialize(), it would be better to set the default value and then call on Deserialize().

How to do it: When there is an error deserializing certain attribute, you may create new instance and try to get, via reflection, the default value for that attribute.

Motivation: onDeserialize() can serve in the same way, but it duplicated the effort of DPU developer, he has to initialize the attribute on two places which may introduce errors.

[tomas-knap]

Do we need onDeserialize() method then?

[skodapetr]

Actually imho yes .. or at least with design of some configurations. Imagine the situation ..
You have extractor that extracts from multiple sources .. and those sources are serialized into the String.
Then you decide to add some metadata to them .. so you do not add new values but you modify the existing ones. Also you may wan't to store then into List<> (or some complex class) so you need onDeserialize method to copy the data from string into the List<>.
Of course you can do this inside the DPU before the configuration is used .. and also inside the dialog before the configuration is used ... or you can do it on one place.

And still you may want to have several transient fields in your configuration and somehow compute them before/after serialization from serialized data.

[tomas-knap]

In case of deserializing configuration from XStream, it works in a way that
firstly the non-param constructor is called, then the fields are set,
right?

On Mon, Mar 10, 2014 at 8:35 AM, Petr Škoda notifications@github.comwrote:

Actually imho yes .. or at least with design of some configurations.
Imagine the situation ..
You have extractor that extracts from multiple sources .. and those
sources are serialized into the String.
Then you decide to add some metadata to them .. so you do not add new
values but you modify the existing ones. Also you may wan't to store then
into List<> (or some complex class) so you need onDeserialize method to
copy the data from string into the List<>.
Of course you can do this inside the DPU before the configuration is used
.. and also inside the dialog before the configuration is used ... or you
can do it on one place.

And still you may want to have several transient fields in your
configuration and somehow compute them before/after serialization from
serialized data.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1292#issuecomment-37158584
.

[skodapetr]

XStream do deserialization .. and set whatever he can .. we watch this process and take a note of all set fields. Then we use reflection to get list of all fields in configuration and if there are fields that has not been set, then we create default configuration (empty ctor) and use getters/setters to copy required values.

[tomas-knap]

Ok. So the basic advice is - if you need any initialization (apart from the
setting of the initial value for persisted fields), which should be done
when deserialization is done or when the new object is built, put it into
onDeserialize method, so that the code is not on two places. Maybe we
should call it postInitialization() instead of onDeserialize()?

On Mon, Mar 10, 2014 at 8:53 AM, Petr Škoda notifications@github.comwrote:

XStream do deserialization .. and set whatever he can .. we watch this
process and take a note of all set fields. Then we use reflection to get
list of all fields in configuration and if there are fields that has not
been set, then we create default configuration (empty ctor) and use
getters/setters to copy required values.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1292#issuecomment-37159376
.