[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: |
|
||||||||
| 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. |