 |
 |
K-T, I can tell you are peeking :) as you can see I am still buried deeply in redoing the data loading page. > 1) The DRP Coordinator (a person) and/or the DBA create all tables for > the DRP results before it starts (using a script based on the > agreed-upon pre-defined schema for the DRP). ok, makes sense. But then it'll be different for L3 data. I was hoping to keep data loading for L2 and L3 as similar as possible. I'll think about it more > 2) Note that we will have single-sky-tile tables at first which can be > dropped (or perhaps kept, if desired) as the main production starts up. I need to understand this better > 3) The DRP must autonomously ingest data into the existing tables as it > progresses. No human intervention should be necessary to do this. agreed > 4) If SDQA discovers a problem that requires dropping data and replacing > it with new data, the DRP Coordinator and/or the DBA will pause > automatic data ingestion while the fix occurs. agreed > 5) It's not clear to me that there's a useful distinction between > "internally released" and "public release" databases/tables. What do > you see as being the differences, and aren't they handled already by > things like access rights and network connectivity? I'd use it as another way of protecting publicly released data. For example, it is common for an admin to keep loading data to internally released data. If the same admin with full privileges mistakenly tries to load to publicly released data, the QMS can stop that. But if it has no way to differentiate between internally and publicly released, it won't. (I guess we could use acl etc to protect, so one can argue it is not essential) > 6) It's not clear to me that there's a useful distinction between "L2" > and "L3" databases. Aren't these differences also handled by > the distributed/non-distributed distinction and access rights? Right, I was thinking about different access rights and (maybe) different set of disks This definitely needs more thinking Thanks, Jacek ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1