View source for Sed and mismatches

You do not have permission to edit this page, for the following reasons:

The action you have requested is limited to users in one of the groups: Autoconfirmed users, emailconfirmed, editors.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Let's find out how to fix mismatches when retrieving a serialized objects.

==Fixing type name mismatches==
The first kind of mismatches that can occur is when a type was renamed or a generic parameters was either added or removed. If you know the old name and the new name, you can pass to <e>{SED_RECOVERABLE_DESERIALIZER}.set_class_type_translator</e> an agent that will return the new type name given the old type name. This agent will be called each time we cannot find the name in the retrieving system.

When all types have found their corresponding type name, we can continue and solve attribute type/name mismatches.

==Fixing attribute type/name mismatches==
There are various kind of mismatches:
*The type of the attribute was changed from X to Z. There are different scenarios:
*#The old type conforms to the new type: if <e>{SED_RECOVERABLE_DESERIALIZER}.is_conforming_mismatch_allowed</e> is true, then no mismatch is reported, otherwise we report one which will be handled when retrieving the object data.
*#The types differ only by their attachment mark: if the new type is attached while the other is not, then we will only trigger a mismatch when retrieving the object data when we get Void; otherwise no mismatch is being raised.
*#If the old type without attachment mark conforms to the new type without attachment mark, we apply first #1 and if True we apply #2 above.
*#The types are completely unrelated: we trigger a mismatch when retrieving the object data.

*The name of some attributes have changed: if an attribute name translator has been provided via <e>{SED_RECOVERABLE_DESERIALIZER}.set_attribute_name_translator</e>, we use this to find out the new name of the attribute and then apply the above in case the type has also changed. If no translator was provided, we simply trigger a mismatch when retrieving the object data.

*Some attributes have been removed: if <e>{SED_RECOVERABLE_DESERIALIZER}.is_attribute_removal_allowed</e> is true, then no mismatch is reported, otherwise we report one which will be handled when retrieving the object data.

==Fixing mismatch with data==
When none of the above was able to automatically address the various mismatches, we trigger a mismatch whenever we are done retrieving an object which has a mismatch.

This is done by calling the <e>correct_mismatch</e> routine from the type which has the mismatch. From that routine, you can have access to an instance of <e>SED_TYPE_MISMATCH</e> and <e>MISMATCH_INFORMATION</e> holding all the information you need to know what is mismatched and all the object data you need to reconnect the attributes.

If you are unable to fix, then you should raise an exception which will be internally understood as not being able to retrieve the storable. At this stage, you can either choose to continue retrieving the rest of the data or stop right there by setting <e>{SED_RECOVERABLE_DESERIALIZER}.is_stopping_on_data_retrieval_error</e>.

Return to Sed and mismatches.

Retrieved from "https://dev.eiffel.com/Sed_and_mismatches"

View source for Sed and mismatches

Navigation

Development

Wiki

Search

Tools