normalization: add normalization of the options #848

eliax1996 · 2024-04-08T15:52:58Z

The options could be of different types:

string
boolean
number
enum
map
list
option

Here I've added an example for each one of them:

STRING:

option example_option = "hello world";

BOOLEAN:

option example_option = true;

NUMBER:

option example_option = 42;

ENUM:

enum ExampleEnum {
  OPTION_ONE = 1;
  OPTION_TWO = 2;
}

option example_option = OPTION_ONE;

MAP:

message ExampleMessage {
  map<string, int32> example_map = 1;
}

option (map_option) = {
  key: "key1"
  value: 42
};

LIST:

message ExampleMessage {
  repeated string example_list = 1;
}

option (list_option) = [
  "item1",
  "item2",
  "item3"
];

OPTION:

option (custom_option) = {
  string_option: "hello world",
  enum_option: OPTION_ONE,
  boolean_option: true
};

The goal of this pr its to start the process of normalization of the schemas initially just for the options in the protobuf types.

About this change - What it does

It changes how the protobuf schema gets normalized before being saved

Why this way

Seems that sorting alphabetically the options its a good way to provide an invariant over the order of the options.

For the reviewers: I'm not completely familiar with protobuf nor the normalizations, please read each line of documentation (of the code and of the pr) and if anything doesn't sound right or you found something that seems wrong please discuss about it!
I've added an example for each type of option just to make sure we are not loosing any important corner case. To me sounds reasonable to order those in any case. Additional normalizations could be added in another pr

1. string 2. boolean 3. number 4. enum 5. map 6. list 7. option Here I've added an example for each one of them: 1. STRING: ``` option example_option = "hello world"; ``` 2. BOOLEAN: ``` option example_option = true; ``` 3. NUMBER: ``` option example_option = 42; ``` 4. ENUM: ``` enum ExampleEnum { OPTION_ONE = 1; OPTION_TWO = 2; } option example_option = OPTION_ONE; ``` 5. MAP: ``` message ExampleMessage { map<string, int32> example_map = 1; } option (map_option) = { key: "key1" value: 42 }; ``` 6. LIST: ``` message ExampleMessage { repeated string example_list = 1; } option (list_option) = [ "item1", "item2", "item3" ]; ``` 7. OPTION: ``` option (custom_option) = { string_option: "hello world", enum_option: OPTION_ONE, boolean_option: true }; ``` The goal of this pr its to start the process of normalization of the schemas initially just for the options in the protobuf types. # About this change - What it does It changes how the protobuf schema gets normalized before being saved # Why this way Seems that sorting alphabetically the options its a good way to provide an invariant over the order of the options. For the reviewers: I'm not completely familiar with protobuf nor the normalizations, please read each line of documentation (of the code and of the pr) and if anything doesn't sound right or you found something that seems wrong please discuss about it! I've added an example for each type of option just to make sure we are not loosing any important corner case. To me sounds reasonable to order those in any case. Additional normalizations could be added in another pr

tvainika · 2024-04-09T05:14:07Z

Support for normalize flag is also needed in POST /subjects/<subject> which returns ID of schema if already registered.

jjaakola-aiven

Options are allowed on message and field level, I'd add the support for these also.

…dpoint

eliax1996

ready to be reviewed again :)