please let me come up again with my old problem of pointers in the ROOT
DB. On my previous questions on this topic, I was strictly recommended to
store data in a ROOT DB like shown in the `event' and ATLFAST example. Let
me recollect this:
All objects of an event should be stored in TClonesArrays, one
TClonesArray for each type. Integer indices describe relations between
table entries. The advantages of this are clear:
* fast vertical access
* good compression possibilities
* TClonesArrays avoid some memory allocation and deallocation
But it's obvious, that this approach also bears some restrictions:
* all objects of one type must be stored in the same array. That might
lead to problems with temporary and semi-temporary objects, i.e. objects
which should not be stored or only be stored under certain circumstances.
* all `integer pointers' point into the same array. This forbids the use
of polymorphism, which is a major advantage of the ROOT system.
* the objects pointed to are not defined by language constructs, the
relations are not stored explicitly in the DB. So any code reading the DB
has to have already built in the additional information about the
relations.
It seems to me that there are many possible applications for such missing
features, e.g. reconstructed decays with generalized particles like
different kinds of tracks and calorimeter information. They could also be
related to different types of detector hits and calorimeter clusters.
One could also have different sets of reconstructed tracks, e.g. simple
hit fits or results of global vertex fits. One might also get a set of
competing reconstructions and store only some of them. These things will
have a rich substructure and will not fit well into `flat' arrays.
ROOT provides part of the necessary power, e.g. the possibility to store
canvases with deep polymorphic substructures. But up to now, I failed to
store parts of my events in a similar way.
The first reason (*) is, that there might be cross-links inside the object
tree. These should not lead to the same object stored twice, there seems
to be a hash table mechanism to avoid this, but I could not make it work
yet.
The second problem is the deleting of the sub-objects. In my event
example, the objects containing the pointers do not necessarily _own_ the
objects pointed to (maybe because of *), that's why I tried to create my
own garbage collection for this. (It failed so far to free all memory of
~1000 events, but I am still struggling.)
My question now: has anyone else found the need of features described here
and maybe solved the two problems? Do I overlook important aspects?
Best regards and thank you very much for the help
Christoph
---------------------------------------------------------------------------
Christoph Borgmeier | Mail: DESY -F15-, Notkestr. 85, 22607 Hamburg
Humboldt Univ Berlin | Phone: +49 40 8998 4850
Email: borg@ifh.de |
---------------------------------------------------------------------------