[INSTRM-763] Changes to schema for CobraConfig and mcsData Created: 08/Sep/19  Updated: 24/Dec/19  Resolved: 24/Dec/19

Status: Done
Project: Instrument control development
Component/s: spt_operational_database
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Normal
Reporter: rhl Assignee: Kiyoto Yabe
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to INSTRM-844 Additional updates to operational schema Done

 Description   

When using CobraConfig it's usually necessary to join to mcsData purely to get the frameId. We should probably denormalise a little further (i.e. add frameId or maybe visitId), and take the opportunity to use the same name in the two tables (centroidx v. mcsCenter_x).

We might want to remove the mcs pixel coordinates from CobraConfig all together; the two tables are used for different things, and can be easily joined when investigating e.g. camera distortions.

While renaming columns it's worth thinking about using a Hungarian-style naming convention (e.g. adding including Pix in all pixel coordinates, and/or MM for all focal plane coordinates), especially when the two coordinate systems both appear in one table.

Currently both tables include information about moves (one via moveId and one via iteration. We should reconsider this too; for example, if mcsData included the nominal position in MCS pixel coordinates we might well use it for convergence analysis rather than CobraConfig; I doubt if we would use both



 Comments   
Comment by hassan [ 22/Oct/19 ]

I propose merging the cobra_config and mcs_data tables. It's not clear to me why the latter is separate.

Comment by Kiyoto Yabe [ 23/Oct/19 ]

Historically, `mcsData` (currently `mcs_data`) was a table just containing an output of mcs_actor for only mcs measurement part, and `CobraConfig` (currently `cobra_config`) was motivated to be a table for only cobra movement part. 

In terms of the database normalization, I think we can merge these two because they have one-to-one correspondence, but I think we should separate two because some of the records in `cobra_config` such as pfi_center will be stored in a different process from the mcs measurement part. 

For your reference, you can find the current schema from here: https://github.com/Subaru-PFS/spt_operational_database/blob/new_schema_oct2019/PFS-DAT-IPM003002-01_pfs_schema.pdf

 

Comment by rhl [ 25/Oct/19 ]

I agree with Kiyoto Yabe; the information in the two tables is available at at different times.

Comment by hassan [ 25/Oct/19 ]

Ok, I see now - if the two tables are populated in two separate processes, the tables should remain separate.

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