Subject:
Re: Another comment concerning Event Store Architecture
From:
David Adams <dladams@bnl.gov>
Date:
Fri, 19 Oct 2001 09:14:51 -0400
To:
Julius Hrivnac <Julius.Hrivnac@cern.ch>
CC:
atlas-database@atlas-lb.cern.ch

I agree that history objects do not and should not allow one to navigate
forward. They allow one to navigate backward to find the algorithm, job
and input data objects used to create a data object. They do not allow 
one to find out what objects were created using a specified data object 
or event.

Instead I expect there would be separate databases that allow one to 
discover which event or data objects exist. Databases is plural here 
because a given object will likely appear in more than one. Examples include
  1. one describing a file,
  2. another for data available at a particular site and
  3. another at CERN containing all approved production data to date.

These databases can be built up from bookkeeping information or by 
examining all the history objects for the data set of interest.

Presumably any of these data bases would be required to be able to 
return all the event or data objects corresponding to a particular 
event ID. This is the answer to the question posed by Julius.

Some or all of these DB's may be required to be able to return all 
data objects created from a specified data object, either directly 
(children) or indirectly (later progeny). This enables one to respond 
to a more difficult request such as:
  Return all ESD's built from tracks using the new fitting algorithm.

da

Julius Hrivnac wrote:

Hi,
   I have another comment concerning the Architecture:

   There are some (possible) requirements, which are not satisfied
   in the current Architecture. For example:
   - User has a reference to some RAW event and she would like to
     find out if there is an ESD (or AOD) for it. She may even ask
     for a special ESD (created using some defined Options).
   - In a similar way, if someone has an ESD, she may want to know
     if there are other ESDs created from the same RAW but using
     different Options (algorithms).
   Such requirements can't certainly be satisfied inside write-once
   environment. One can imagine a "metadata" which could carry all
   necessary information. Those metadata would then be modifiable.
   They would be, in fact, the real database on top of the Event
   file store. Do we want to have something like that ? Proposed History
   objects are certainly not rich enough for that. There is also    certain connection with Bookkeeping database.

               Julius



-- 
David Adams                      desk: 631-344-6049
Brookhaven National Lab          fax: 631-344-5078
PAS group, Building 510A         email: dladams@bnl.gov
Upton, NY 11973-5000             http://www.usatlas.bnl.gov/~dladams

____________________________________________________________________
This mail has been sent to everyone on the atlas-database list
____________________________________________________________________