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

features/unmarshal: implement unmarshal_unique #140

Merged
merged 5 commits into from
Sep 17, 2024

Conversation

GiedriusS
Copy link
Contributor

@GiedriusS GiedriusS commented Sep 13, 2024

Implement unmarshal_unique that is like unmarshal but calls unique.Make() on each string. The idea is to keep only one copy of a string around with gRPC marshaling/unmarshaling pools on.

No idea how to test this in unit tests but this change works in our project.

Fixes #139.

Implement unmarshal_unique that is like unmarshal but calls
unique.Make() on each string. The idea is to keep only one copy of a
string around with gRPC marshaling/unmarshaling pools on.

No idea how to test this in unit tests but this change works in our
project.

Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@vinted.com>
features/unmarshal/unmarshal.go Outdated Show resolved Hide resolved
features/unmarshal/unmarshal.go Outdated Show resolved Hide resolved
Convert the option into a field option. Update README.md.

Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@vinted.com>
@GiedriusS
Copy link
Contributor Author

@vmg thanks for the very quick review 🙇 I have added unsafe.String and convert this into a field option. PTAL when you have some free time. Thanks in advance!

Copy link
Member

@vmg vmg left a comment

Choose a reason for hiding this comment

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

Love the new implementation. Could you please add some tests for the new feature? Main thing to test would be that unmarshalling the same message twice results in the same string. You can use https://pkg.go.dev/unsafe#StringData to verify the the string has been properly interned. Thank you!

Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@vinted.com>
@GiedriusS
Copy link
Contributor Author

GiedriusS commented Sep 16, 2024

👍 🚀 added a test using unsafe.StringData as suggested

}

extend google.protobuf.FieldOptions {
optional Opts options = 999999;
Copy link
Member

Choose a reason for hiding this comment

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

What happened here? Why is this set to 999999? This seems like something that could conflict. Did the previous 64102 collide or such?

Copy link
Contributor Author

@GiedriusS GiedriusS Sep 16, 2024

Choose a reason for hiding this comment

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

It's my first time writing a field option. How do we know if any number doesn't collide with some other number that someone chose?

Copy link
Member

Choose a reason for hiding this comment

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

There's no way to be 100%, but the idea is namespacing the field options with a high enough number. In this case we've choseen 641xx as the ID range for vtprotobuf, so any number in that range would be reasonable to use. 999999 is, well, a number unlikely to collide either, but it's outside of the range we've chosen for the library.

Copy link
Member

Choose a reason for hiding this comment

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

A good number to choose would be 64150, that way we have 64101-64149 reserved future MessageOptions, and 64150-64199 reserved for FieldOptions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see, thank you for the thorough explanation. I switched it to 64150.

Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@vinted.com>
GiedriusS added a commit to thanos-community/vtprotobuf that referenced this pull request Sep 17, 2024
planetscale#140 requires >=1.23.0

Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@vinted.com>
@GiedriusS
Copy link
Contributor Author

Trying to bump the Go version here: #141

Copy link
Member

@vmg vmg left a comment

Choose a reason for hiding this comment

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

Looks great! Thank you so much for this contribution. I think it'll be generally very useful. Could you merge main to pick up the 1.23 upgrade?

@vmg vmg merged commit 6f2963f into planetscale:main Sep 17, 2024
1 of 2 checks passed
@GiedriusS GiedriusS deleted the unique_unmarshal branch September 18, 2024 06:14
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.

Add ability to intern all strings
2 participants