[INSTRM-1091] Add butler persistence to/from opDb Created: 16/Oct/20  Updated: 22/Apr/22  Resolved: 22/Apr/22

Status: Won't Fix
Project: Instrument control development
Component/s: pfs_utils
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: cloomis Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: PFI, SPS, opDb
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Story Points: 4

 Description   

The ICS butler in pfs_utils currently persists to files, generally either YAML or FITS. Per many recent discussions, some objects need to be persisted to opDb instead. Support that for things like:

cobra = self.butler.get('cobraGeometry', idDict)
self.butler.put(cobra, 'cobraGeometry', idDict)

The filesystem persistence mechanism generally did not address versioning, leaving that up to external tools and procedures (e.g. someone calling 'git commit' for updated files in pfs_instdata).

Likewise with the opDb. If the schema supports persistence, e.g. with an update time column, then we get versioning. Else not.

The existing filesystem map for the above example is:

configMap['cobraGeometry'] = dict(template="pfi/cobras/{moduleName}/{cobraInModule}/geometry.yaml",
     loaderModule='ics.cobraCharmer.cobra')

with a magic load(path) in the loaderModule, and a .dump(path) in the returned class.

I do not have confidence that there will always be a one-to-one object-to-table mapping, so am not sure whether naming a table in the butler is useful. So I guess I'd make that:

configMap['cobraGeometry'] = dict(opDb=True,
                                  loaderModule='ics.cobraCharmer.cobra')

and add loadOpDb(idDict) and .dumpOpDb(idDict) function & method. Allow useful info to be stuffed in idDict.

Use the spt_operational_database library routines to wrap opDb access, so I do not need to think about database implementation details.



 Comments   
Comment by cloomis [ 22/Apr/22 ]

Our opdb access routines are covered by spt_operational_database. If we really want storage-agnostic butler access this ticket can be rephrased/reopened.

Generated at Sat Feb 10 16:31:48 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.