feat(schema): define database entry for hardware #405
Conversation
| "type": "string" | ||
| }, | ||
| "version": { | ||
| "title": "Version ID", |
There was a problem hiding this comment.
Shouldn't we use the tag there? They are immutable
There was a problem hiding this comment.
hm, but API endpoints will use the versionID (UUID) not tags to manage versions, right? And the main entry ID is already not human readable so it seems the the version ID does not have to be either.
Basically, if we move from reference by name to reference by ID, then it feels like versions should also be reference by ID and not by tag. But I can see that, since the database ID already uniquely identifies the entry, using a version tag string also has no ambiguity.
Happy for a tie-breaker from @domire8
There was a problem hiding this comment.
since the database ID already uniquely identifies the entry
Why do we need the version or tag anyway then? I would find the human readable tag better
There was a problem hiding this comment.
Why do we need the version or tag anyway then?
Versioned database entries all have a common parent ID. The version is optional, so when omitted it points to the latest working version. When a version ID is supplied, it takes the corresponding versioned entry associated with the parent ID. A version ID without a parent ID is mostly useless unless you have raw database access.
In general, since it's not required to use the UUID for the version when we can use the string tag, and the string tag is unique, immutable, and more readable let's go with the string tag.
The application parser / our API can then do the extra work to figure out the version ID from the tag
| "type": "string" | ||
| }, | ||
| "version": { | ||
| "title": "Version ID", |
There was a problem hiding this comment.
since the database ID already uniquely identifies the entry
Why do we need the version or tag anyway then? I would find the human readable tag better
Description
This defines a common database_entry type in the application schema that includes an id and optional versionID for contents of the local database. This is then used in hardware subschema so that hardware descriptions can be referenced by ID rather than by name.
Currently, I have a oneOf condition that requires either
urdf(string) or the newdatabase_entry(object) property. I could also have done it so that the single requiredurdfproperty is oneOf string or object. Please let me know your preference.Review guidelines
Estimated Time of Review: 3 minutes
Checklist before merging: