Storable and versioning

Introduction

Originally Eiffel Software's object serialization was written in C and was proposing the following alternative:

• basic: the same version of the executable on a particular platform can store and retrieve objects.
• general: different versions of the executable on a particular platform can store and retrieve objects.
• independent: different versions of the executable running on different platforms can store and retrieve objects.

Initially you could only retrieve an object if and only if the storing and retrieving system where exactly the same (i.e. same number of attributes and same types for all of them). A couple of years ago, we added to the independent version a mechanism to fix mismatches (i.e. object of the same type but the type had its number of attributes changed, or the type of attributes have changed). The mechanism is known as correct_mismatch and you can benefit from it by redefining the correct_mismatch routine from MISMATCH_CORRECTOR whenever you change the content of a class.

Unfortunately this code was written in C and was not much compatible with object layouts in .NET. This is what prompted us to write a pure Eiffel version of our C storable mechanism. This mechanism is known as SED (SErialization-Deserialization). Thanks to SED, one could serialize objects from and to .NET as long as they had the same content. Contrary to the C version, SED is proposing the following alternatives:

• session: the same running version of the executable can store and retrieve objects
• basic: same as the C version
• independent: same as the C version

What is missing is the general alternative which was deemed useless over the years as independent made more sense, especially with the extended facility such as correct_mismatch.

However SED has some limitations:

• it cannot handle properly user defined expanded types.
• it does not implement correct_mismatch

For the 6.6 release, we hope to solve the first limitation.

Versioning

Is correct_mismatch the best way to solve mismatch? Not quite because even if you have the same number and same kind of attributes there could be a mismatch. An example is in the ELKS class HASH_TABLE where from one implementation to the next of HASH_TABLE we decided that the deleted_marks array should have one more entry. To solve that problem, we forced a mismatch by adding a fake attribute to HASH_TABLE which in turn would trigger a mismatch. But this solution was really a workaround and the penalty is that fake added attribute.

For 6.6, we are planning on adding a storable_version note clause to a class that will be used upon retrieval to find out if there is a mismatch or not. The content of storable_version would be user defined and will be used by the storable mechanism to perform a quick check upon retrieval. If they are different then we trigger a mismatch, otherwise we proceed like today.

Currently the storable_version value is not inherited, so if you had an attribute to an ancestor class, you would need to change all its descendants.

Feel free to comment for discussing this further

Happy Eiffeling,

Manu