Dear ROOT developers and users, 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 | ---------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:31 MET