Hi Christian,
Christian Holm Christensen wrote:
>
> 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.
>
I have never advocated this solution as a general solution. The solution
with writing to a different file always work anyhow. In the Christian's case,
the update frequency is so low and likely under his control that he can assume
that two writers do not write to the file (if he has this control).
> > 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)?
This seems obvious and does not deserve a long speech. That is why we are
advocating the combined use of ROOT with a RDBMs systems when transactions
are required for a run/file catalog for example. In the above, one second was my
estimation to write 2 MBytes in compressed mode to a file (being pessimistic).
>
> > 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.
>
I repeat. This could indeed be implemented in ROOT. We do not see any reasons to
rush in this direction since simple tools like mySQL (or equivalent) are there.
Implementing transactions can be done with a separate transaction server.
> 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.
>
We had several iterations on this point last fall. We want to discourage
updating branches of a tree. An alternative with Tree friends exists.
> > > 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.
>
Not a very efficient way to make a query to a Tree. We already have
TTreeResult, TTreeRow, TTree::Query. Anything beyond that is likely to be
application dependent and can be coded with a few lines of code.
Rene Brun
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:38 MET