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
There a _rawJSON field in every struct in the go SDK. This is counter to go's standard json unmarshalling where values without a field and json annotation aren't stored. As I understand from @amckinney, this field is meant to preserve the original server response for debugging purposes.
The use of this rawJSON field doubles the size memory used by the structs in all usage, including our customer production environments where memory is a concern. Additionally, this makes writing verifications for tests that use the SDK more difficult because we have to account for the rawJSON field in the expected verification.
Why would it be useful?
This would be useful for go SDKs targeted towards memory-sensitive customers and for writing tests.
Describe the solution (optional)
Implement a generator option (say disableRawJSON) that disables this functionality.
The text was updated successfully, but these errors were encountered:
This is a totally reasonable feature request. You can actually see the rationale in the PR that introduced the feature in this PR (you'll notice it calls out your concern w.r.t. size too).
We'll follow-up with a disableRawJSON configuration field when we have the capacity to do so!
Problem description
There a _rawJSON field in every struct in the go SDK. This is counter to go's standard json unmarshalling where values without a field and json annotation aren't stored. As I understand from @amckinney, this field is meant to preserve the original server response for debugging purposes.
The use of this rawJSON field doubles the size memory used by the structs in all usage, including our customer production environments where memory is a concern. Additionally, this makes writing verifications for tests that use the SDK more difficult because we have to account for the rawJSON field in the expected verification.
Why would it be useful?
This would be useful for go SDKs targeted towards memory-sensitive customers and for writing tests.
Describe the solution (optional)
Implement a generator option (say
disableRawJSON
) that disables this functionality.The text was updated successfully, but these errors were encountered: