Re: [Caml-list] Long-term storage of values

[Martin Jambon <martin.jambon@ens-lyon.org>]

On Thu, 28 Feb 2008, Basile STARYNKEVITCH wrote:

> Dario Teixeira wrote:
>>  Hi,
>>
>>  Suppose I have a value of type Story.t, fairly complex in its definition.
>>  I wish to store this value in a DB (like Postgresql) for posterity.
>>  At the moment, I am storing in the DB the marshalled representation
>>  of the data; whenever I need to use it again in the Ocaml programme
>>  I simply fetch it from the DB and unmarshal it.
>>
>>  This works fine; there is however one nagging problem: the marshalled
>>  representation is brittle.  If Story.t changes even slightly, I will
>>  no longer be able to retrieve values marshalled with the old version.
>
>
> It is even theoretically a very difficult problem. There have been some 
> publications by Cristal, Moscova, Gallium people at INRIA.
>
> Assuming you have no abstract types, no objects, and no closures, and no 
> polymorphisms i.e. that there is a *.ml source file containing all the type 
> definitions. Then the types are composed by base types (int, string, ...), 
> sums, records, and perhaps arrays.
>
> Then you could consider what are the deltas on the type definition.
>
> In a sum like type sumt = A of t1 | B of t2 | C
> you might consider what happens when you remove let say B, or add let's say a 
> choice | D of t3
>
> In a record, consider likewise what happens when adding or removing a field.
>
> Etc....
>
>
> The details are very complex (at least to me, who tried unsucessfully to work 
> on this during my year at INRIA).
>
> Maybe a semi-hand-crafted generator could help. Adding polymorphisms, 
> closures, objects, abstract types is a big mess.

I sure do believe you.
However, speaking with no experience in this domain, it seems to me that 
if we restrict the transition to a certain subset of operations, it can be 
possible to define a mapping using some Camlp4 tool such as Deriving 
(well, that's what I was told, assuming I interpreted correctly).

For instance:
- adding a record field: a default value is injected
- removing a record field: just remove it
- adding a variant: do nothing since it doesn't exist in the old data
- changing a type arbitrarily (such as changing a type foo1 into foo2
   everywhere): provide a map function that would override the default map
   function for such nodes. 
- functional and abstract values: left as-is

I think I'll soon have to deal with such a problem, so any further 
suggestions are welcome.


Martin

--
http://wink.com/profile/mjambon
http://martin.jambon.free.fr