This is a work in progress area for ITuple with complex structure. This document collects the main concepts behind this issue and it is meant to incorporate the comments,suggestions and resolutions that emerge from the on-going parallel e-mail forum discussion. By complex structure we mean the possibility of supporting a folder-like data arrangement inside an ITuple. As in AIDA we already have the concept of Folders within ITree we will try not to use the word "folder" to avoid confusion.
An improvement is the current ITuple design is needed to allow the user to store data with an internal structure (i.e. event->tracks->hits kind of cascade). This can be obtained with minimal changes to the current schema.
The main concept is that additional structure is achieved by allowing an ITuple to store another ITuple. An example of what an user should do to create and fill an ITuple with additional internal structure follows:
To access the data stored in the ITuple the user will have to do:
The only change required to the ITuple interface is to add the method:
ITuple getTuple( int index );
that returns the ITuple at the column's position index.
A change is also needed to the aida.dtd to allow for XML saving and restoring of the internal structure for an ITuple. As the columns, their names and their types are specified in the top level ITuple, all is needed is to save the data stored in the internal ITuple.
To distinguish an ordinary "entry" in a "row" from the one corresponding to the internal ITuple we need a new element "entryITuple" and to modify the "row" element to account for its presence.
The XML output for the example above will look like:
The internal structure we discussed above can be achieved by creating
the desired ITules when needed and store them as Objects in the current
ITuple schema. This implementation would not require any changes to
the current ITuple. Nevertheless we think that this kind of implementation
is inefficient and goes against the current AIDA standards.
To create a new set of ITuples inside the main loop, the user will have to access the ITupleFactory. This will automatically put the newly created ITuple in the ITree in which the top-level ITuple is living. This is probably inappropriate as the internal ITuples should not be part of the ITree.
Moreover when creating ITuples we allocate memory that might be left unused. A trim() method would be required at the expence of speed.
The above example on how to create and fill an ITuple will then look like:
while the one on how to access the data is unchanged.
Rather that creating an ITuple each time, we create the needed ITuples only once when the top level ITuple is created. We then append the data when the corresponding addRow() method is called. This way the user does not have to create an ITuple insed the event loop and we solve the above efficiency problem. The two approaches are represented schematically in the figure below.
The price to be paid is the need of the
new ITuple method mentioned above ( getTuple(index) ) that returns
the ITuple in a configuration ready to be filled ( the getObject() method
returns the SAME ITuple in a configuration corresponding to the "current"
position of the top-level ITuple ).
Another small price is that for each internal ITuple, we have to create
an additional column ("helper" in the figure below) in the the top-level
ITuple to keep track of where the data starts and ends for a given entry.
Please note that with this implementation the ITuple automatically supports random access if we provide a setRow() method.
In this schema it is necessary to define the nested ITuples at the top ITuple level. The examples in this document used the following conventions:
There are two ways to create an ITuple using the create() method of an ITupleFactory:
The second create() method was used in the first example in this document; the code below shows how to create the same ITuple using the other ITupleFactory's create() method.
Version: $Id: tupleWithStructure.shtml,v 1.13 2002/03/26 02:52:15 tonyj Exp $