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
|
