Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add New ProtobufEncodingMode for Nullable and Google-Compatible Types #374

Merged
merged 16 commits into from
Oct 20, 2023

Conversation

lwlee2608
Copy link
Contributor

Add ProtobufEncodingMode

  1. VERTX_NULLABLE,
    In this encoding mode, the converter uses a non-standard protobuf encoding to allow boxed types (e.g., Integer, Double) and String to be nullable. This encoding mode is intended for use when communicating with another Vert.x converter that supports nullable values.

  2. GOOGLE_COMPATIBLE
    In this encoding mode, the converter uses the standard protobuf encoding, which is compatible with Google's protobuf ecoder. Null values are not allowed for boxed types and String in this mode.

Ladicek and others added 8 commits September 29, 2023 16:52
Previously, field numbers were always assigned automatically during protobuf
schema generation, based on declaration order of properties in a data class.
It is very easy to modify the data class in a way that changes field numbers
unintentionally, which introduces a breaking change to the protobuf schema.

This commit introduces the annotation `@ProtobufField` as a mechanism for
explicitly providing field numbers, as well as a `FieldNumberStrategy` enum
(used in `@ProtobufGen.fieldNumberStrategy`) to select how field numbers
should be assigned. There's a manual strategy and two automatic strategies.

Further, `@ProtobufGen.reservedFieldNumbers` and `reservedFieldNames` allow
specifying reserved field numbers / names, similarly to the protobuf language
itself. Reserved field numbers and names are verified at compile time.

The fields in the protobuf schema are generated in the field number order,
not in the property declaration order. The serialization/deserialization
code in generated converters also uses field number order. This is to make
sure that a Vert.x-generated and `protoc`-generated serializers produce
outputs that are not just mutually _compatible_, but also binary _identical_.
@vietj
Copy link
Member

vietj commented Oct 16, 2023

is this ready for review @lwlee2608 ?

@lwlee2608
Copy link
Contributor Author

@vietj yes

Copy link
Member

@vietj vietj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a minor rename

@vietj vietj modified the milestones: 4.5.0, 5.0.0 Oct 20, 2023
@vietj vietj merged commit f1002f4 into eclipse-vertx:master Oct 20, 2023
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants