Thanks, K-T. Some responses:
If the node exists in the CSS but has no data, should nothing be returned, or should an exception be raised?
It will return empty dict for now. I'm not sure if there is any use case for that, if anyone wants to make empty nodes then we should handle it "normally".
Should the exception message mention the key (which is not actually correct if the data is in JSON format) or just the node name?
It's complicated, I'll need to check the logic again when checking for .json key should be done vs non-json. I think message should mention the actual key because of this ambiguity, or it can mention both node name and a key.
I take it the existence check on creation is just for safety and that colliding creates are also caught in the create method. Otherwise, there could be a race condition.
Mostly yes, but I don't think races are possible here. Populating CSS with nodes in my view is not an activity which can be done concurrently by multiple clients.
In the Trac document (which is migrating to Confluence?), in the possible future where the node name is just the host name plus port number, are the host name and port number values even necessary? What if they disagreed?
No comment on Confluence. I think we should keep node name to be just a unique ID and not assign any meaning to it, it should give us extr flexibility in case we decide to do something differently.
There's no documentation of the .json option in the Trac page.
JSON is an implementation detail for now, not exposed anywhere yet (but we should document it). I believe Daniel unpacks JSON when he clones CSS data into memory for qserv use.
It should be noted that .json overrides a plain node name. Should the case of both keys existing be caught?
There are use cases when both keys are there, in ZK at least there is a distinction between key value and key children. In case of packed JSON data only children are stored as JSON and key value is still stored as regular key.
The error message "Node does not exists" should be "Node does not exist".