Adding ID field to each metadata message type owned by the metadata store #134
Conversation
| { | ||
| // The unique identifier of the UUT instance | ||
| // This value should be a string representation of a GUID. | ||
| string id = 1; |
There was a problem hiding this comment.
I chatted with Nick about these added fields, and his inclination is that we should name these fields as id, rather than as (for instance) uut_instance_id. (Note that blue-box IDs like Step.step_id and TestResult.test_result_id currently use a more fully qualified name. It sounds like there may be interest in changing this though.)
There was a problem hiding this comment.
I don't care whether we standardize on message_id or id, I just care that we use it consistently between the data store and metadata store messages.
There was a problem hiding this comment.
@nick-beer, should I add an issue concerning needing to update/refactor for use of id in the DataStoreService as well? Any other thoughts?
There was a problem hiding this comment.
yeah - makes sense to me to update them and keep everything in sync.
| { | ||
| // The unique identifier of the UUT instance | ||
| // This value should be a string representation of a GUID. | ||
| string id = 1; |
There was a problem hiding this comment.
I don't care whether we standardize on message_id or id, I just care that we use it consistently between the data store and metadata store messages.
5 participants
AB#3410683
What does this Pull Request accomplish?
This set of changes adds an
idfield to each metadata store entity message type.Why should this Pull Request be merged?
This facilitates referencing the IDs of these metadata store entities in other parts of the API, such as when creating a
TestResultand associating it with existing metadata.What testing has been done?
Implementation and automated testing added for these changes as part of the core Data Store Service / Metadata Store Service