Changes between Version 6 and Version 7 of ippReleaseManagement

Timestamp:

Sep 20, 2012, 4:07:42 PM (14 years ago)

Author:

bills

Comment:

--

ippReleaseManagement

@@ -142 +142 @@
  * state - current status of the release. Several values have been identified
    * active - results for the release are currently available to the community
-   * pending - release identified, construction may have begun, but the data is not yet ready to be available by default
+   * pending - release identified, construction may have begun, but the results not yet ready to be available by default
    * archive - the release contains the results of a previous processing of the data that has been superseded.
+   * drop - the results of the release have been abandoned and should be ignored
  * dataRelease - If not null, the dataRelease value in the corresponding PSPS tables.
 
@@ -166 +167 @@
 corresponding to that release is identified by dataRelease 0, while 3PI.GR1 refers to the future
 LAP release which will begin construction soon. Once that release gets under way it's state will be set
-to active while 3PI.GR0 will be set to "archive"
+to active while 3PI.GR0 will be set to "archive". XXX: insure that PSPS uses a different dataRelease ...
 
 The two SAS entries refer to PS1_SAS_08 and PS1_SAS_09.
 
 Now we turn our attention to tables that record the actual contents of a release. Single frame results
-are represented by the table relExp (released exposure) and relSkycell (released skycell). (Similar table
-will be defined for difference data products in the future).
+are represented by the table relExp (released exposure) while stacks are represented by relSkycell 
+(released skycell). (We expect that in the future a similar table will be defined for difference stage 
+data products).
 
 == Released Exposure ==
@@ -200 +202 @@
 | time_stamp | datetime         | YES  |     | NULL    |                | time of last update to row
 +------------+------------------+------+-----+---------+----------------+
+Note: this is a prototype. The actual table will use foreign key constraints where appropriate.
 }}}
 
 This table will allow us to easily identify for a given exposure and release the derived data products that were used
-to construct the results for the exposure. Here are a couple of examples
-
-
+to construct the results for the exposure.
+
+Each time an exposure is released a new row will be added to the table.
+
+Here are a couple of examples showing the releases for one of the SAS exposures:
 {{{
 mysql> mysql> select ippRelease.releaseName, relExp.* from ippRelease join relExp using(rel_id) where exp_id = 356773;
@@ -219 +224 @@
 
 
-
-
-
-
-
+Note that the list of ids are the same except for the add_id. This is because SAS_v9 was constructed 
+using the SAS_v8 pixels. For single frame exposures only the DVO injest and calibration was redone. This is
+indicated by the change in add_id.
+
+==== state / data_state / flags ====
+There are three columns related to the state of the released exposure. We haven't yet settled on which of
+these data are required to manage the releases. Information that we might want to record include
+ * state - active, drop, archive (note that the release state
+ * has the released exposure been imported into PSPS
+ * did the calibration apply ubercal. Perhaps: if so which version?
+ * was the data the result of a recalibration, relphot, relastro, something else ...
+
+=== Life cycle of a relExp ===
+We envision the following potential events in the history of a released exposure for the nightly science
+releases
+ * created during nightly science processing once the warp has been completed before the addRun is processed. State active.
+ * updated to include the add_id of the addRun 
+
+For a "GR" release
+ * row is created when addstar is performed. State set to pending.
+ * row is updated when ipptoPSPS is run. At that time the calibration data is updated with the resulting values and the state is changed to reflect the PSPS export.
+
+
+