Difference between revisions of "Talk:Persistence predicates"

Latest revision as of 07:44, 4 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.

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). --Colin-adams 08:31, 4 October 2007 (CEST)

Agent keyword was missing

I just noticed your point about gadget.id - I had missed out the keyword agent following the body: 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 infer the need to store gadget.id, 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. --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. --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. --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.

--Colin-adams 18:44, 4 October 2007 (CEST)