Talk:Persistence predicates - Revision history

Colin-adams: Class for serialization

2007-10-04T16:44:35Z

Class for serialization

Clemahieu at 15:59, 4 October 2007

2007-10-04T15:59:07Z

Colin-adams: Examples added

2007-10-04T09:26:49Z

Examples added

Colin-adams: Agent keyword was missing

2007-10-04T07:05:58Z

Agent keyword was missing

Colin-adams at 06:31, 4 October 2007

2007-10-04T06:31:01Z

Alexander Kogtenkov: Transformation at store time

2007-10-03T19:49:23Z

Transformation at store time

Alexander Kogtenkov: Added a request to extend the example

2007-10-03T19:21:29Z

Added a request to extend the example

New page

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

← Older revision		Revision as of 16:44, 4 October 2007
Line 45:		Line 45:
	This would seem a lot easier in my opinion.		This would seem a lot easier in my opinion.
	--[[User:Clemahieu\|Clemahieu]] 17:59, 4 October 2007 (CEST)		--[[User:Clemahieu\|Clemahieu]] 17:59, 4 October 2007 (CEST)
		+
		+	== Class for serialization ==
		+
		+	Creating a separate class for serialization was my first thought too when I encountered the problem.
		+
		+	That is fine if you only face the problem once. It becomes very tedious as soon as you reached the second or third class, never mind the rest.
		+
		+	--[[User:Colin-adams\|Colin-adams]] 18:44, 4 October 2007 (CEST)

← Older revision		Revision as of 15:59, 4 October 2007
Line 39:		Line 39:
	If red, green and blue were re-defined as routines in terms of hue, saturation and value, then a mis-match would occur, so this is no better than the current situation with mismatch-correctors. So they have to still be (redundant) attributes, and must still be persistent so that new storables can be used on the old system.		If red, green and blue were re-defined as routines in terms of hue, saturation and value, then a mis-match would occur, so this is no better than the current situation with mismatch-correctors. So they have to still be (redundant) attributes, and must still be persistent so that new storables can be used on the old system.
	--[[User:Colin-adams\|Colin-adams]] 11:26, 4 October 2007 (CEST)		--[[User:Colin-adams\|Colin-adams]] 11:26, 4 October 2007 (CEST)
		+
		+	== Necessity ==
		+	Is this type of functionality needed? If a serialized object of a class A contains more information than what is needed to be serialized, wouldn't it be easier to create a class B that has a creation feature that accepts a parameter of type A, copies the needed information out of A and then serialized the new object of B? When deserializing, A has a creation procedure accepting a parameter of type B and the process is reversed and caches are recreated?
		+
		+	This would seem a lot easier in my opinion.
		+	--[[User:Clemahieu\|Clemahieu]] 17:59, 4 October 2007 (CEST)

← Older revision		Revision as of 09:26, 4 October 2007
Line 23:		Line 23:
	Anyway, I still have to provide a more comprehensive example.		Anyway, I still have to provide a more comprehensive example.
	--[[User:Colin-adams\|Colin-adams]] 09:05, 4 October 2007 (CEST)		--[[User:Colin-adams\|Colin-adams]] 09:05, 4 October 2007 (CEST)
		+
		+	== Examples added ==
		+
		+	I have now filled out a more complete example, and so I have removed the "under construction" label.
		+
		+	Alexander, your RGB -> HSV example is quite interesting, now I think about it a bit more.
		+
		+	I suppose the scenario goes a bit like this:
		+
		+	1) There are three attributes, red, green and blue, which are persistent.
		+
		+	2) New variables, hue, saturation and value are added. To initialize these from an old-format storable, a restoration routine would be needed.
		+	I'm not sure how the routine is supposed to know whether or not restoration must be performed, given that default values would be reasonable. Perhaps restoration routines must be restricted to having detachable reference arguments.
		+
		+	If red, green and blue were re-defined as routines in terms of hue, saturation and value, then a mis-match would occur, so this is no better than the current situation with mismatch-correctors. So they have to still be (redundant) attributes, and must still be persistent so that new storables can be used on the old system.
		+	--[[User:Colin-adams\|Colin-adams]] 11:26, 4 October 2007 (CEST)

← Older revision		Revision as of 07:05, 4 October 2007
Line 15:		Line 15:
	As for the long-term issue, I explicitly said I was not addressing this in the article. Using storables for a short-to-medium term cache is good. For longer term persistence, a proper database schema is needed, I think (I shall be interested to see what comes out of the persistence project).		As for the long-term issue, I explicitly said I was not addressing this in the article. Using storables for a short-to-medium term cache is good. For longer term persistence, a proper database schema is needed, I think (I shall be interested to see what comes out of the persistence project).
	--[[User:Colin-adams\|Colin-adams]] 08:31, 4 October 2007 (CEST)		--[[User:Colin-adams\|Colin-adams]] 08:31, 4 October 2007 (CEST)
		+
		+	== Agent keyword was missing ==
		+
		+	I just noticed your point about <e>gadget.id</e> - I had missed out the keyword <e>agent</e> following the <e>body:</e> tag.
		+	This produces a closed agent (and therefore incorporates the id value). The idea was that somehow the closed agent gets stored in the storable. But maybe this is not possible and/or desirable (if the code for the agent has changed in the meantime, then it is must be better to use the updated code). In which case the storing mechanism can <em>infer</em> the need to store <e>gadget.id</e>, but only for the purpose of closing the agent built at restore time. Does that make sense?
		+
		+	Anyway, I still have to provide a more comprehensive example.
		+	--[[User:Colin-adams\|Colin-adams]] 09:05, 4 October 2007 (CEST)

← Older revision		Revision as of 06:31, 4 October 2007
Line 10:		Line 10:

	: 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.		: 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.
		+
		+	The incompleteness of the example is why the page is still marked as under construction.
		+
		+	As for the long-term issue, I explicitly said I was not addressing this in the article. Using storables for a short-to-medium term cache is good. For longer term persistence, a proper database schema is needed, I think (I shall be interested to see what comes out of the persistence project).
		+	--[[User:Colin-adams\|Colin-adams]] 08:31, 4 October 2007 (CEST)

← Older revision		Revision as of 19:49, 3 October 2007
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.