Jacek,

> > 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

	For L3 data loaded all at once from an external catalog, a DBA
would also create the table.  For L3 data loaded by a user's
computation, the user would create the table in advance.  For L3 data
created using "CREATE TABLE AS SELECT", the table is created as part of
the query.  In all cases, the table exists before the data appears.

> >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

	This is the first month of the annual cycle, in which we do a
"mini-DRP" pretending that a single sky tile is the entire sky in order
to verify the processing.  The results of this are then thrown away, and
the real DRP is begun.

> >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)

	I'd say that we disable writing to the table through normal
access mechanisms.  Even an admin would then need to re-enable writing
(using a separate command) to be able to mess with the data.

-- 
Kian-Tat Lim, LSST Data Management, [log in to unmask]

########################################################################
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