Difference between revisions of "Sed and mismatches"
(New 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 gene...) |
|||
| Line 9: | Line 9: | ||
There are various kind of mismatches: | There are various kind of mismatches: | ||
#The type of the attribute was changed from X to Z. There are different scenarios: | #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_INDEPENDENT_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 old type conforms to the new type: if <e>{SED_INDEPENDENT_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. | ||
| + | :*The types are completely unrelated: we trigger a mismatch when retrieving the object data. | ||
Revision as of 10:03, 2 March 2010
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 {SED_INDEPENDENT_DESERIALIZER}.set_class_type_translator 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
{SED_INDEPENDENT_DESERIALIZER}.is_conforming_mismatch_allowedis 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.
- The types are completely unrelated: we trigger a mismatch when retrieving the object data.
- The old type conforms to the new type: if
