Skip to content
This repository has been archived by the owner on Apr 20, 2021. It is now read-only.

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

Open
tomas-knap opened this issue Mar 4, 2014 · 5 comments

Comments

@tomas-knap
Copy link
Contributor

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
Copy link
Contributor Author

Do we need onDeserialize() method then?

@skodapetr
Copy link
Contributor

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
Copy link
Contributor Author

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

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
Copy link
Contributor

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
Copy link
Contributor Author

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

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
.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants