Hi Chris, At first, I agree. If a field is not absolutely required, we should make it optional.
However, some fields may be required. For example, to open a region, you need to specify the region to be opened. In case a required field is not required in the future any more, due to some big architecture/design change, we can use a deprecation window. Thanks, Jimmy On Mon, Aug 6, 2012 at 3:39 PM, Chris Trezzo <ctre...@gmail.com> wrote: > Hi All, > > I was looking through the .proto files and noticed there are a lot of > fields that are marked as required. I am by no means a protobuf expert, but > I was wondering what advantage do we actually get in making fields required? > > I understand that if we don't use the required keyword we would have to > implement custom application logic, but the flexibility we gain from having > all the fields optional seems to outweigh that work. In addition, we will > already have to add logic to HBase to handle version compatibility, so it > seems natural to implement the required logic as part of that layer. This > would allow us to change or delete any message field and maintain wire > compatibility. > > Quote from the protobuf language guide ( > https://developers.google.com/protocol-buffers/docs/proto): > > "*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 > requireddoes more harm than good; they prefer to use only > optional and repeated. However, this view is not universal." > > Thoughts? > > Thanks, > Chris Trezzo
