staticID in databroker

[SebastianSchildt]

Recently uuids in VSS have been replaced wirth the options for "staticID", the idea is the same: Having a (numeric) ID linked to a VSS path.

See https://github.com/COVESA/vss-tools/blob/master/docs/id.md for a descritpion of the tooling side. While theoretically an implementer can create the uids "any way he likes", the default is a hashing based mechanism https://github.com/COVESA/vss-tools/blob/ef95db1d26e1175c1b9ae7f210225d626bdb5e81/src/vss_tools/vspec/vssexporters/vss2id.py#L59.

In the end a vspec export, i.e. yaml may contain aditonal 32 bit "staticUID" fields.

I think it would be good, if databroker would support those as well, i.e. allow a query or a set to use the staticUID as an alternative to the path.

API aside, I was thinking how to best implement it databroker side. The main structure is

kuksa-databroker/databroker/src/broker.rs

Lines 96 to 100 in 7596725

	pub struct Database {
	next_id: AtomicI32,
	path_to_id: HashMap<String, i32>,
	entries: HashMap<i32, Entry>,
	}

One idea would be in case of a value for staticUID in vspec just using those as the i32 Hashmap Index. That leaves the corner case, that theoretically it is thinkable that only part of the elements in a vspec do have StaticIDs (that would be weird, but may happen, then it might be mixed with the static counter and theoretically this may lead to weird collisions)

An alternative would be an additonal Hashmap for the staticUid. (Could be staticUid_to_Uid or storing "references" to the same entries as in the existing table if that is doable in Rust)

Any opinions?

[erikbosch]

A possible approach could be to iterate over the signal list twice, something like

for <all signals>
  if <signal has static id>
    "Do a sanity check that key is not already used"
    "add signal to <entries> using static id as key"
for <all signals>
  if <signal not has static id>
    while <next_id already is used as key>
      next_id++ 
    "add signal to <entries> using next_id as key"
    next_id++

API wise are you thinking of that a client either will give a uint32 or a string as identifier? If uint32 is given we will search directly in , otherwise first in <path_to_id>