Home Comments

3.5b: how to expire a data member

blairblair Member Blair ZajacOrganization: Sony Pictures ImageworksProject: VnP ✭✭
I haven't read all the new documentation, but did read New in Ice 3.5. I didn't see any documentation on how to expire or age out a struct data member or method argument you no longer want. In other words, how do you make something optional after the fact?

Could you do what some Google engineers suggest for protobuf:
Required Is Forever You should be very careful about marking fields as required. If at some point you wish to stop writing or sending a required field, it will be problematic to change the field to an optional field – old readers will consider messages without this field to be incomplete and may reject or drop them unintentionally. You should consider writing application-specific custom validation routines for your buffers instead. Some engineers at Google have come to the conclusion that using required does more harm than good; they prefer to use only optional and repeated. However, this view is not universal.

So one would make everything optional?

Maybe you could also add to this page how one checks if a data member was provided? Are there new isSet*() style methods? This was save some time looking around the docs for a comprehensive overview of this new feature.

I should state, we're very excited about optional data members, thanks for working on them!

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    Thanks for your suggestion, we'll consider improving the release notes.

    The semantics of non-optional data members didn't change with Ice 3.5. If you change its type, its order, remove it or make it optional, it will cause a Slice mismatch. If you have peers using different versions of this Slice you will end up with marshaling exceptions.

    It's up to you to decide if you should make everything optional or not. I would expect that not everything needs to be optional. For example, it's probably safe to make the first and last name data members in a "Person" Slice class non-optional data members.

    The article you linked is focused on the encoding changes, I recommend checking out the optional data member documentation in the Ice manual and for a detailed description of how they are mapped in the different language mappings supported by Ice 3.5b. You can also take a look at the Ice/optional demo.

    Cheers,
    Benoit.
Sign In or Register to comment.