You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
…field numbers in the range 1 through 15 take one byte to encode, including the field number and the field's type (you can find out more about this in Protocol Buffer Encoding). Field numbers in the range 16 through 2047 take two bytes. So you should reserve the numbers 1 through 15 for very frequently occurring message elements. Remember to leave some room for frequently occurring elements that might be added in the future.
Although FeatureSpec is registry (meta)data that is not used in high-throughput RPCs or Kafka messages currently, it doesn't seem like a bad idea to move the TFDV stats and reserve low-number fields while we can. The cost is low.
The text was updated successfully, but these errors were encountered:
Within the Feast v0.5 release cycle these fields have not been in a
release yet, so it's safe to renumber them.
The motivation is reserving the lower-numbered fields for optimal
encoding, referenced in the patch.
Closesfeast-dev#667
Within the Feast v0.5 release cycle these fields have not been in a
release yet, so it's safe to renumber them.
The motivation is reserving the lower-numbered fields for optimal
encoding, referenced in the patch.
Closes#667
As discussed at #655 (comment) and according to protobuf spec guidance:
Although
FeatureSpec
is registry (meta)data that is not used in high-throughput RPCs or Kafka messages currently, it doesn't seem like a bad idea to move the TFDV stats and reserve low-number fields while we can. The cost is low.The text was updated successfully, but these errors were encountered: