-
Notifications
You must be signed in to change notification settings - Fork 1
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
FOGL-9302 Support for signed 32-bit integer values in the metric #47
base: develop
Are you sure you want to change the base?
Changes from 3 commits
c53fe82
96aadfd
fbd868b
5571d37
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -153,7 +153,7 @@ message Payload { | |
optional MetaData metadata = 8; // Metadata for the payload | ||
optional PropertySet properties = 9; | ||
oneof value { | ||
uint32 int_value = 10; | ||
int32 int_value = 10; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do not change auto generated file, this need not be changed .. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is necessary for handling signed integers. This generic MQTT SparkplugB subscriber addresses the issue for any data type, eliminating the need for ctypes |
||
uint64 long_value = 11; | ||
float float_value = 12; | ||
double double_value = 13; | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the implementation outlined in the DRAFT PR (accessible here), we are addressing the handling of the
metric.datatype
field to determine how to properly interpret the data contained inmetric.int_value
.Overview of
metric.datatype
The
metric.datatype
indicates the type of data represented bymetric.int_value
. This field informs the application whether the integer value should be treated as a signed or unsigned integer.Handling of Integer Values
Protobuf Encoding: In Protocol Buffers (protobuf), both signed and unsigned integers are encoded as unsigned integers. This means that when we receive an integer value through the protobuf payload, it does not inherently carry information about whether it is signed or unsigned.
Type Casting Based on
datatype
:metric.datatype
field to determine how to interpret themetric.int_value
.metric.datatype
, we can decide if the integer should be treated as a signed integer (e.g., usingctypes.c_int
) or if it should remain as an unsigned integer.Implementation Changes in the Draft PR
datatype
indicates that the value is signed, we cast it using:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To cast signed integer values in Protobuf is generally not recommended. While it might work in some cases, it's not the best or most portable approach.
a)
ctypes
can introduce portability issues if you're targeting environments with different architectures.b) It also adds unnecessary overhead for simple operations, like casting or type-checking, which can be done much more directly in Python.
c) Protobuf already provides a clean and efficient way to handle integer types, including signed and unsigned integers
IMO, we should use Protobuf’s own type system and avoid unnecessary casting through ctypes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The solution in this pull request requires changes to the auto-generated code, which seem to introduce portability issues. I'm unsure about the specifics of the portability concerns you are pointing. Could you please point me to the relevant documentation for Protocol Buffers that explains these issues and offers a foundation for my understanding?