Sed and mismatches - Revision history

Manus: /* Open issue */

2010-03-23T18:18:35Z

Open issue

← Older revision		Revision as of 18:18, 23 March 2010
Line 35:		Line 35:

	==Open issue==		==Open issue==
	The issue is related to the handling of missing values for attached types. When retrieving an object if an attached attribute has ~~not~~ value, the attribute cannot be used within the execution of `correct_mismatch'. Thus we need a special compiler support so that in `correct_mismatch' attached attributes are considered not set. But this is not enough, if you depend on a attribute which also has a mismatch which haven't been fixed yet, you cannot assume anything about the attachment status of its attributes. This constraint has to be limited to the type checking of `correct_mismatch'.		The issue is related to the handling of missing values for attached types. When retrieving an object if an attached attribute has no value, the attribute cannot be used within the execution of `correct_mismatch'. Thus we need a special compiler support so that in `correct_mismatch' attached attributes are considered not set. But this is not enough, if you depend on a attribute which also has a mismatch which haven't been fixed yet, you cannot assume anything about the attachment status of its attributes. This constraint has to be limited to the type checking of `correct_mismatch'.

Manus: /* Fixing mismatch with data */

2010-03-04T21:51:47Z

Fixing mismatch with data

← Older revision		Revision as of 21:51, 4 March 2010
Line 33:		Line 33:

	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>.		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>.

			==Open issue==
			The issue is related to the handling of missing values for attached types. When retrieving an object if an attached attribute has not value, the attribute cannot be used within the execution of `correct_mismatch'. Thus we need a special compiler support so that in `correct_mismatch' attached attributes are considered not set. But this is not enough, if you depend on a attribute which also has a mismatch which haven't been fixed yet, you cannot assume anything about the attachment status of its attributes. This constraint has to be limited to the type checking of `correct_mismatch'.

Manus at 22:20, 2 March 2010

2010-03-02T22:20:21Z

← Older revision		Revision as of 22:20, 2 March 2010
Line 1:		Line 1:
			[[Category:Persistence]]
	Let's find out how to fix mismatches when retrieving a serialized objects.		Let's find out how to fix mismatches when retrieving a serialized objects.

Manus at 21:06, 2 March 2010

2010-03-02T21:06:18Z

← Older revision		Revision as of 21:06, 2 March 2010
Line 1:		Line 1:
	Let's find out how to fix mismatches when retrieving a serialized objects.		Let's find out how to fix mismatches when retrieving a serialized objects.

			==What is a mismatch?==
			Before trying to find out how to fix a mismatch we need to provide a definition. A mismatch is whenever the layout or description of a type has changed compared to what was stored. Currently you have the following type of mismatches:
			*The class version has changed
			*An attribute has been added or removed
			*An attribute had its type changed

			Some mismatch can be silently resolved (see below) and some requires an explicit action from the user to map the old data to the new.

	==Fixing type name mismatches==		==Fixing type name mismatches==

Manus at 19:49, 2 March 2010

2010-03-02T19:49:05Z

Manus: /* Fixing mismatch with data */

2010-03-02T19:48:01Z

Fixing mismatch with data

← Older revision		Revision as of 19:48, 2 March 2010
Line 19:		Line 19:

	==Fixing mismatch with 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 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_INDEPENDENT_DESERIALIZER}.is_stopping_on_data_retrieval_error</e>.		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_INDEPENDENT_DESERIALIZER}.is_stopping_on_data_retrieval_error</e>.

Manus: /* Fixing mismatch with data */

2010-03-02T19:46:34Z

Fixing mismatch with data

← Older revision		Revision as of 19:46, 2 March 2010
Line 19:		Line 19:

	==Fixing mismatch with 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 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_INDEPENDENT_DESERIALIZER}.is_stopping_on_data_retrieval_error</e>.		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 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_INDEPENDENT_DESERIALIZER}.is_stopping_on_data_retrieval_error</e>.

Manus at 19:46, 2 March 2010

2010-03-02T19:46:11Z

← Older revision		Revision as of 19:46, 2 March 2010
Line 17:		Line 17:

	*Some attributes have been removed: if <e>{SED_INDEPENDENT_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.		*Some attributes have been removed: if <e>{SED_INDEPENDENT_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 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_INDEPENDENT_DESERIALIZER}.is_stopping_on_data_retrieval_error</e>.

Manus: /* Fixing attribute type/name mismatches */

2010-03-02T19:33:55Z

Fixing attribute type/name mismatches

← Older revision		Revision as of 19:33, 2 March 2010
Line 14:		Line 14:
	*#The types are completely unrelated: we trigger a mismatch when retrieving the object data.		*#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, 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.		*The name of some attributes have changed: if an attribute name translator has been provided via <e>{SED_INDEPENDENT_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_INDEPENDENT_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.		*Some attributes have been removed: if <e>{SED_INDEPENDENT_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.

Manus: /* Fixing attribute type/name mismatches */

2010-03-02T19:33:02Z

Fixing attribute type/name mismatches

← Older revision		Revision as of 19:33, 2 March 2010
Line 13:		Line 13:
	*#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.		*#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 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, 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_INDEPENDENT_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.

← Older revision		Revision as of 19:49, 2 March 2010
Line 2:		Line 2:

	==Fixing type name mismatches==		==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_INDEPENDENT_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.		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.		When all types have found their corresponding type name, we can continue and solve attribute type/name mismatches.
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_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.		*#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.		*#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 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_INDEPENDENT_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.		*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_INDEPENDENT_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.		*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==		==Fixing mismatch with data==
Line 23:		Line 23:
	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.		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_INDEPENDENT_DESERIALIZER~~}.is_stopping_on_data_retrieval_error</e>.		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>.