bluesky: why datum document does not have uid?

Working to update the SpecFileWriter() to be compatible with AreaDetector and new (since 2017-09) API. Found two new documents in the stream from bp.count(): resource and datum.

Expected Behavior

expect to find a uid in every document emitted from RunEngine

Current Behavior

uid is MIA

Possible Solution

Ensure uid is added to all documents emitted by RunEngine.

Steps to Reproduce (for bugs)

See https://github.com/BCDA-APS/APS_BlueSky_tools/issues/29

Context

Trying to solve one problem and this came up.

Your Environment

‘OPHYD_VERSION’: ‘1.2.0’, ‘BLUESKY_VERSION’: ‘1.3.3’ arch = linux_x86-64

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 22 (19 by maintainers)

Most upvoted comments

I agree with https://github.com/NSLS-II/bluesky/issues/1070#issuecomment-405708492 as well. Making mongodb produce the UUID seems attractive but would not solve the original problem. It also makes this document type dependent on the databroker backend.

The discussion has been good to identify the basic motivations for the current implementation. Summarizing:

datum_id was optimized for low overhead, based on a common UUID and an incrementing integer
community was built around this exact name, thus changing it to uid would cause problems
creating a new UUID for each datum document introduces overhead, perhaps unacceptable
duplicating datum_id into uid to maintain a common document schema seems wasteful

Having agreed to keep the current implementation, I could close this issue without further action. Agree?

prjemian on Jul 17, 2018

In my view, putting the same value in two places is slightly worse than dealing with the inconsistency in names, especially since datum_id is already different than the others due to its uuid4/int structure and will have to be handled specially by some consumers anyway. But I do not feel strongly about this.

danielballan on Jul 17, 2018