-
Notifications
You must be signed in to change notification settings - Fork 3
feat: flag data model #156
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
Conversation
…legates to std::optional<T> overloads
|
This pull request has been linked to Shortcut Story #207650: Flag data model. |
5a36e4b to
0158bf0
Compare
0158bf0 to
a0fbc31
Compare
|
|
||
| TEST(SDKDataSetTests, DeserializesZeroSegments) { | ||
| auto result = | ||
| boost::json::value_to<tl::expected<data_model::SDKDataSet, JsonError>>( |
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.
Some of these tests change in the (not yet issued) evaluator PR, due to slight changes in the data model. So if you notice some field that should be required (or the other way around), it might be fixed there.
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.
Yeah, I am depending a bit on testing for that. Mainly checked conditions matched manes.
This PR builds on #153, extending the deserialization to flag data.
I've added to the
PARSE_FIELDmacro to handle the following cases:PARSE_FIELD. In other words, if the field is omitted or null, it will be filled in with a default value. Most common scenario.PARSE_FIELD_DEFAULT.optional:PARSE_CONDITIONAL_FIELD. For example, the value""wouldn't be a valid default for a unique key.PARSE_REQUIRED_FIELD. Usage of this should be rare; the test would be if the SDK is totally unable to function without this.To achieve this, I've made the
tag_invokes operate onexpected<optional<T>, JsonError's, instead ofexpected<T, JsonError.We could potentially revert that (and instead add a new enum case to
JsonError), but I figureoptionalis a good representation of null/omitted. I think I need to actually try removing it to determine if it results in a better API.One thing lacking is better error messages - we use kSchemaFailure everywhere but we now have the ability to report exactly what was missing/wrong type, etc.