Talk:Persistence predicates

Revision as of 01:26, 4 October 2007 by Colin-adams (Talk | contribs) (Examples added)

--Alexander Kogtenkov 21:21, 3 October 2007 (CEST) It would be nice to extend the example to see where the 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 - 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, 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)