Tracks and crates need a means of identification in the high-level API, but the actual nature of a unique identifier may vary between database formats (integer id, UUID, so on). As such, a combination of database type and vendor-specific identifier may be needed.
One approach could be to have a std::variant of all types of identifier, and an enum of all supported database types. Other implementations may also be suitable.
This will the current assumption that all unique track/crate identifiers will fit into a int64_t.
An alternative way of thinking of this could be that the track, crate, etc. objects in the high-level API actually are the aforementioned 'id' structs. They should follow rule-of-five.
Tracks and crates need a means of identification in the high-level API, but the actual nature of a unique identifier may vary between database formats (integer id, UUID, so on). As such, a combination of database type and vendor-specific identifier may be needed.
One approach could be to have a
std::variant
of all types of identifier, and anenum
of all supported database types. Other implementations may also be suitable.This will the current assumption that all unique track/crate identifiers will fit into a
int64_t
.