Re: [boost] Versioning, Was: [filesystem][program_options][serialization][test]fromcomp.lang.c++

From: bwood (brass_at_[hidden])
Date: 2006-05-17 23:54:51

This is a MIME encoded message.

--=_a9d9f751c76b812a6486c9a3474db964
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Peter Dimov writes:
> bwood wrote:
>> David Abrahams wrote:
>>> bwood <brass_at_[hidden]> writes:
>>>
>>>> Along the lines of what Lapin is thinking, I think B.Ser's
>> "versioning"
>>>> support is problematic.  For example, consider wanting to move (or
>>>> delete) a data member out of a type between versions 1.1 and 1.2.
>>>> B.Ser needs that member to remain in the type in order to support
>> 1.1.
>>> No, you just read it and throw it away.
>>>
>>>        if (version == 11)
>>>        {
>>>            type_of_deleted_member ignored;
>>>            ar & ignored;
>>>        }
>> Wait a minute.  The code above looks like you may have focused on
>> deleting a member and not relocating it.  "ignored" isn't coming
>> from anywhere else with a 1.1 client and it needs to be stored
>> somewhere.  Also if a 1.2 server is sending to a 1.1 client,
>> it doesn't matter whether the member has been deleted or
>> relocated, it still has to send the right thing back.
> 
> This is an inherent property of the communication between an 1.2
server
> and 
> an 1.1 client; any versioning system would have this problem. If you
> want to 
> talk to 1.1 code, you have to be able to produce 1.1 data. This is
true
> even
> 
> if the underlying serialization layer doesn't support versioning at
all,
> it 
> just makes it harder for you. 
> 

"Any versioning system would have this problem."  

There's an alternative approach though that doesn't have the 
problem.

                            release
                1.1         1.2         1.3         1.4
-----------------------------------------------------------------
class name    Account     Account     Account_13  Account_13

The class name incorporates the release in which it was last
changed.  As usual, the 1.3 version of the server is required 
to support 1.1 clients.  To do this the server is built with 
both the Account and Account_13 definitions.  Sorry for being 
obvious, but it uses Accounts when talking to 1.1 clients and 
Account_13s when working with 1.3 clients.

When only additions occur between releases, I think this 
hierarchy would work

        AccountBase
             |
          Account 
             |
        Account_13

If members need to be relocated out of Account in 1.3, the 
hierarchy might be

        AccountBase
           /    \
      Account  Account_13

In either case, the 1.3 server may use polymorphism and 
accomplish what is needed pretty simply.  With a 1.1 client,
it produces 1.1 data by executing what originally was 1.1
code.  This is helpful from a testing perspective.  The only
way I can think of to introduce errors with 1.1 clients would 
be to accidentally use Account_13 instead of Account.  

I think this approach supports relocated members between
releases and could be used to build systems that are easier 
to test than systems that use "versioning."  

Regards,
Brian Wood
http://www.webEbenezer.net

PS:   I don't have Le Chaud Lapin's email address.  I think he
might be interested in this discussion.

--=_a9d9f751c76b812a6486c9a3474db964--