Traverse InfluxDB in Corto UI

[hendrenja]

@SanderMertens will need to advise Corto best practice for this.

Currently, measurements are saved as full paths. Corto needs to support walking the hierarchy through the Corto UI.

Example:

/historcial/animals/cats/tiger
/historcial/animals/cats/lion
/historcial/animals/dog/labrador 

These measurements are discrete entries. Corto needs to know how to walk the path. @SanderMertens Should a query for histrocial/animals return a corto_void_o object if there is not a matching measurement for the select expression, but the select expression does partially match existing measurements (/historical/animals/cats/tiger)?

[SanderMertens]

This is indeed caused by how corto_select works. If the historical and historical/animals objects are not available (either in the store or from a mount) then you will not be able to navigate to historical/animals/cats/tiger because there are "missing links".

This is similar to having a website with unreachable pages. You can't reach the pages through links, though you can refer directly to them. If you would do corto_select("historical/animals/cats/tiger") (or the equivalent in the UI: select historical/animals/cats/tiger) I expect this to work.

To properly address this, you have to create the missing objects in the store, or create a mount that provides these objects.

Automatically showing these objects as void objects is dangerous; this may conflict with the actual type of the objects (if they exist somewhere else). A typical scenario could be where objects have been partially synced to a store and you are still waiting for historical/animals. By returning this object as void, you'd violate a key constraint, which is that objects may never change type.

This could have many nasty side-effects, where the void object would be synchronized to other datastores with the wrong type. That would violate eventual consistency- you would observe a state for an object remotely that the source of the object never created.

Long term it could be possible to have objects in the store that have an unknown type; however this would be a major feature to implement.

[hendrenja]

@SanderMertens I think this issue should be moved to another repository. There is value in recording this history. As we have discussed through Slack conversations, this is not a mount issue. Instead, the issue is poor data modeling that exposes holes in data paths.