Hi Christian and Rene,
On Sat, 12 Jan 2002 21:37:57 +0100 (MET)
Rene Brun <Rene.Brun@cern.ch> wrote
concerning "Re: [ROOT] TFolder or TDirectory?":
> Hi Christian,
>
> Considering that the update frequency is very low: only a few hundred
> times per week, and that the total size of the information is also
> very small (you said about 20,000 employes: considering 100 bytes
> per employee, this makes around 2 MBytes), I would recommend
> - to use the TFolder structure in memory with the hierarchy
> as you described it in your original mail.
> - to write the top folder with folder->Write at each transaction
> as a new key in the same file or in a different file.
How's that gonna help? One transaction A, write top;1, but while it's
executing another transaction B, comes along and writes top;2. Now A
and B finished, and transaction C comes along. Now which one of top;1
and top;2 should be used? Should the server merge the two tops or
what? I'm asking 'cause I'm curious, and I don't know how I would go
about implementing transactions in ROOT.
> The time for one transaction should be below 1 second.
Uh, what it transactions take longer than that? Suppose you want a
transaction to lasts as long as it takes to write 1G Alice events to
disk (not via the transaction though, but the transaction is logging
it)?
> On Sat, 12 Jan 2002, cstrato@EUnet.at wrote:
> > Although some of your slides suggest MySQL as Run/File catalog for
> > the Event Store I must admit that I do not believe in RDBMS.
We've used MySQL with ROOT in BRAHMS. So far, it works fine. We
started out looking at Objectivity, but soon found it was way to
clumbersome for our needs.
> > Browsing the book “The Object Data Standard: ODMG 3.0” from
> > the members of the ODMG, one can see that most classes described
> > in the book are already implemented in ROOT. One of the few
> > classes missing is class TTransaction {begin(), commit(),
> > abort()}.
With the advent of TRef and TRefArray, I believe you're right, since
these classes allow for many-to-many and one-to-many relations in
TTree's between entirely different branches.
However, the transaction protocol is really essential if ROOT is to be
a (distributed) database system on a very large scale.
Oh, one thing. How would you handle partial fills of a tree. Suppose
you have a TTree with branch A and B, but you only want to update
branch A, and not make a new entry in branch B? At fill time it may
not be that bad, but at read time, you may get into trouble if the
default CTOR does some wierd stuff, like setting members to
non-invalid (that is valid) values, so that the entry looks like it's
good, while it's really empty. I remember I had a problem like this
some time ago (a long time ago in fact) when I was looking at the
possiblity of using ROOT as the database backend of the BRAHMS run and
conditions catalog. It may have been fixed somehow after that.
> > I have already started to implement this class in a way which is
> > sufficient for my purposes, and it seems to work fine.
Sounds good. Can it be generalised to something that's generally
usable? If so, why don't you make it avaliable to be intergrated
into ROOT?
Have you also made some sort of setup for a remote server and clients?
Such an example could be very useful to everybody I think.
> > My main problem is to implement a hierarchical structure in the
> > main file which is not only browsable but also searchable.
To this end, it would be nice to have some sort of SQL search
functions in TTree. I believe it's doable. What is needed is an SQL
parser and a translator from SQL to the regular ROOT selection
mechanism.
Yours,
Christian Holm Christensen -------------------------------------------
Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
DK-2200 Copenhagen N Cell: (+45) 28 82 16 23
Denmark Office: (+45) 353 25 305
Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:38 MET