Subject:
Re: muon digit container design
From:
Hong Ma <hma@pony.phy.bnl.gov>
Date:
Thu, 4 Oct 2001 16:17:07 -0400 (EDT)
To:
David Adams <dladams@bnl.gov>
CC:
Torre Wenaus <torre@wenaus.com>, Srini Rajagopalan <srinir@bnl.gov>, Pavel Nevski <nevski@bnl.gov>, Yuri Fisyak <fisyak@bnl.gov>, Alex Undrus <undrus@bnl.gov>

> 
> Thanks for your comments. We have somewhat different models.
> 
> You have a collection of regional collections in your persistent store 
> and present exactly the same view in memory.


Not exactly. We only define what the container looks like
in the transient store.  How you persistify the container is a different
matter.   See below. 


> 
> I have completely divorced the transient and persistent views. I believe 
> the typical application for the digit collection (including the HLT) is 
> to construct the collection from a pointer to the raw data and
> then access the data through the collection without ever writing to or 
> reading from persistent store.


You have to consider "raw data" as a type of persistent event
source.  And you don't want the collection to hold a pointer to raw data,
or any persistifiable objects. 


> 
> I would either unpack the data completely or unpack pieces on demand. 
> The demand might be for a specific channel or for a region of the 
> detector. The regions for these requests and the regions appropriate to 
> the raw data need not be the same.


They don't HAVE to be the same.  But would be more efficient if
they are closely related. 


> 
> On those rare occasions where the digits were to be written to 
> persistent store (root or objectivity), I would write them as a single 
> collection in a space-saving form. When reading them back I would do it 
> in their entirety. I don't expect this format to be used for the HLT and


It may be a rare occasion in practice when we go into production
in 2006, but we heard from David Rousseau in the last meeting that we
want to persistify transient Raw Digit to  Objy (or any other database).
You can consider that as a requirement.  At least he wants that for
SiTrackerDigit in DC0. 


> 
> I don't have any speed requirement on the read from persistent store but 
> this requirement seems to be driving your design. I may be 
> misunderstanding an important point. Let me know a use case if this 
> should be added as a requirement.
> 

If I understand your points correctly, you would choose to have
different MuonDigitContainer implementation in EF and offline environment. 
Then, you are required to have a Abstract Base Class (ABC) for this
container.  That ABC is what algorithms will have dependency on. 
This way, the algorithms can be run in online and offline environment. 
By offline environment, I mean  reading Digit objects from Objy. No Raw
Event whatsoever.   

	Besides, in your implementation for your online
MuonDigitContainer, you will have to manage the partial unpacking.

	The DigitContainer we proposed should work in both online and
offline environment.   No need for an ABC.   Different converters are
needed, of course.   It may be somewhat less efficient when you want to
access all digits, which presummably happens in the offline env. 
When writing DigitContainer to Objy, you may choose
to write all collections together.  Even though each collection is one
data object in store, you really do not have to write one persistent
object per collection if you think that is inefficient.   It is a choice
you have to make when you write a  converter for the MuonDigitContainer (
which should inherit from  DigitContainer< MuonDigitCollection > ). 

	Hong.