[rucksack-devel] Rucksack's serializer: slot order problems?

[Tayssir John Gabbour]

Hi Arthur!

Arthur Lemmens wrote:
>   2. Try to store and load some kind of schema info, just like we do for
>      persistent classes.
>
>      A bit more difficult to implement, but we can probably use most of
>      the existing schema implementation, so it shouldn't be too difficult.
>      It should also be able to handle class redefinitions.

Makes sense. So, during loading, a schema object always comes before
the object it describes. And if DESERIALIZE-CONTENTS sees such a
schema object, it'll silently stuff it into a table, and return the
next normal object in the stream.


Advantages that I can guess:

    * More robust "Slot mismatch" error than we have now. (If we
      simply change the order of slots in a class definition, it fails
      silently and corrupts the object.)

    * Upon slot mismatch, we can give (say) a restart to just do our
      best to load the damn object, with whatever slots are usable. ;)

    * This option #2 seems to have the best parts of the other two,
      without too much of their disadvantages.

    * If a bunch of objects of the same type were redefined to have
      different slots, no problem -- each will be preceded by a
      correct schema object.


(Of course, I'm not that familiar with the other parts of Rucksack, so
maybe I'm making no sense... ;)


All best,
Tayssir


On Thu, May 22, 2008 at 11:57 AM, Arthur Lemmens <alemmens at xs4all.nl> wrote:
> I'm not sure about the best way to fix this.  Here are some options:
>
>  1. Try to guarantee a fixed order for the slots, e.g. by sorting the
>     list of slot names before saving or loading the slot values.
>
>     This is probably the cheapest solution (in terms of speed and storage),
>     and it should be easy to implement.  But it can still fail after
>     redefinitions of non-persistent classes.
>
>  2. Try to store and load some kind of schema info, just like we do for
>     persistent classes.
>
>     A bit more difficult to implement, but we can probably use most of
>     the existing schema implementation, so it shouldn't be too difficult.
>     It should also be able to handle class redefinitions.
>
>  3. Whenever we save a slot value, also save the slot name.  This is
>     simple and robust, but also seems very expensive.
>
> At the moment I'm inclined to go for solution #2, but I'd be interested
> in other opinions.