Difference between revisions of "Talk:Persistence predicates"
m (Added a request to extend the example) |
m (Transformation at store time) |
||
Line 1: | Line 1: | ||
--[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 21:21, 3 October 2007 (CEST) | --[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 21:21, 3 October 2007 (CEST) | ||
It would be nice to extend the example to see where the <e>gadget.id</e> attribute is serialized (given that the attribute <e>gadget</e> is not serialized at all). | It would be nice to extend the example to see where the <e>gadget.id</e> attribute is serialized (given that the attribute <e>gadget</e> is not serialized at all). | ||
+ | |||
+ | == Transformation at store time == | ||
+ | |||
+ | --[[User:Alexander Kogtenkov|Alexander Kogtenkov]] 21:49, 3 October 2007 (CEST) | ||
+ | The proposed scheme assumes that some attributes need to be stored and some - not. However, it's possible that the object model is changed over time, but backward compatibility as well as interoperability with other applications is still required. For example, the original program used the RGB color model with the attributes corresponding to the main colors. Over time it turned out that another model, say, HSV one, is more approriate for the associated algorithms and the attributes were replaced by the new ones. Both models cover the same range of spectrum but use different attribute sets. | ||
+ | |||
+ | For example, the systems A and B use the original RGB coding scheme and the new system A' uses new HSV scheme. For interoperability between all these products (given that they are used on multiple machines and cannot be immediately updated, or even worse, the system B is no longer maintained), it's essential to stick to the original storable format. It means that there should be a way to store new attributes of HSV model using the old RGB style. | ||
+ | |||
+ | : On the other hand, the new development can go on and new systems are designed to use HSV model from the beginning. There is no need to use the old format anymore, given that the new systems A' are able to store the data in a new format as well. As far as I can see, this can be achieved by the predicate on the corresponding attributes that tell whether they need to be stored "as is" or not. This behaviour is easily achieved using the proposed technique with predicates if there is also a way to store data in the old format. |
Revision as of 10:49, 3 October 2007
--Alexander Kogtenkov 21:21, 3 October 2007 (CEST)
It would be nice to extend the example to see where the gadget.id
attribute is serialized (given that the attribute gadget
is not serialized at all).
Transformation at store time
--Alexander Kogtenkov 21:49, 3 October 2007 (CEST) The proposed scheme assumes that some attributes need to be stored and some - not. However, it's possible that the object model is changed over time, but backward compatibility as well as interoperability with other applications is still required. For example, the original program used the RGB color model with the attributes corresponding to the main colors. Over time it turned out that another model, say, HSV one, is more approriate for the associated algorithms and the attributes were replaced by the new ones. Both models cover the same range of spectrum but use different attribute sets.
For example, the systems A and B use the original RGB coding scheme and the new system A' uses new HSV scheme. For interoperability between all these products (given that they are used on multiple machines and cannot be immediately updated, or even worse, the system B is no longer maintained), it's essential to stick to the original storable format. It means that there should be a way to store new attributes of HSV model using the old RGB style.
- On the other hand, the new development can go on and new systems are designed to use HSV model from the beginning. There is no need to use the old format anymore, given that the new systems A' are able to store the data in a new format as well. As far as I can see, this can be achieved by the predicate on the corresponding attributes that tell whether they need to be stored "as is" or not. This behaviour is easily achieved using the proposed technique with predicates if there is also a way to store data in the old format.