Database Distribution: Rules on SEQNO, INSERTDATE and CREATIONDATE

• SEQNO
  Within any given table sequence numbers must be unique throughout all databases in the collaboration. To ensure this bands of sequence numbers are allocated to selected databases that are to act as sources of data. This reduces the management task to one of ensuring that the sequence numbers are unique to the database. Source databases and allocated bands of sequence numbers are as follows:-

  Database site	IP Address	Sequence number range
  NearDet	?	100000000 - 199999999
  FarDet	minos-offline.minos-soudan.org	200000000 - 299999999
  CalDet	pcminos01.cern.ch	400000000 - 499999999

  If other databases act as database sources they can be allocated bands as required.

  Processes that use the DBI, and in particular the DbiWriter to write data, will comply as this interface allocates SEQNOs and records the last allocated sequence number in a special table called GlobalSeqNo. Any process that does not use the DBI must ensure they comply. One way to do this would be to use the same DBI method as is used by DbiWriter:-

  Int_t DbiCascader::AllocateSeqNo(const string& tableName, Int_t requireGlobal = 0, Int_t dbNo = 0) const to allocate SEQNOs. Naturally any table maintained in part by DbiWriter and in part externally could result duplicated SEQNOS and the GlobalSeqNo table must be updated to reflect numbers allocated externally.

  The UGLI tables have their own conflict avoidance scheme

• CREATIONDATE
  Creation dates (UTC) are used to resolve ambiguities when the DBI is selecting the best data; it uses the data with the latest creation dates. This date should be the date when the database data was created but only if the data has universal validity or if creating multiple sets data corresponding to all runs and processing is ordered by run. If this is not the case then Overlay Creation Dates should be use. See the Concepts sections of the Database Interface chapter of the User Manual. DbiWriter supports Overlay Creation Dates.

• INSERTDATE
  The insertion date (UTC) is the date when the data was inserted into the local database. These dates play two important roles:-
  1. For rollback, i.e restoring the database to its state on a specified date, which is done in the DBI by ignoring data with insertion dates after that date.
  2. For distribution using the DBM system, which determines what changes need to be propagated by checking insert dates.
  The DbiWriter and the DBM system set insertion dates correctly. Other systems that write database tables need to comply. This could be complicated if the system was a two part one:-
  • First create an ASCII file.
  • Later use some MySQL utility to import it
  as it would require the system that created the file at step 1 to know the exact time at which the utility at step 2 would be run! To avoid this a convention is employed:-
  • Any INSERTDATE that is greater than 1 January 1st 2030 is treated as undefined. During export such dates are set back to a few minutes before the current time.
  So long as any system follows this convention, DBM will take care of the INSERTDATE date. The slight drawback of this scheme is that the dates will lag behind the true insertion time, so roll-back won't be right between the time the data gets inserted and the next DBM export job gets run. However so long as DBM updating takes place frequently, this lag should not be serious.

1. Allocate a new SEQNO.
2. Create and store a new validity record with this SEQNO and with CREATIONDATE and INSERTDATE set to the current date.
3. Create and store the associated main table rows.

UGLI Conflict Avoidance Scheme

    Dd00SSppp

where

    Dd :  10=Near, 20=Far-normal, 21=Far-shield, 4=CalDet
    SS :  "series"
    ppp:  plane #