Re: [ROOT] TFolder or TDirectory?

From: Rene Brun (Rene.Brun@cern.ch)
Date: Sat Jan 19 2002 - 19:42:29 MET


Hi Christian,


On Sat, 19 Jan 2002, cstrato@EUnet.at wrote:

> Dear Christian and Rene
> 
> I apologize for answering so late but I was at a meeting for the whole week.
> 
> Thank you for this interesting discussion to which I would like to comment:
> 
> First, I am afraid Christian is expecting too much from my trials to implement
> something analogous to a very primitive OODB. Furthermore, currently, I am
> working on a single-user version only to see if this is possible. A limited
> multiuser version would then be the next step.
> As I mentioned, my class TTransaction is a primitive trial to implement this
> function in a way which is sufficient for my purposes. Currently, I am only
> at the begining, however, at a later stage I can show you my implementation,
> it would be great to get some advice.

Before going too far with your proposed TTransaction, let's discuss the
specs. I do not think that one can implement a secure TTransaction with
one single process. You need a server.

> 
> Coming back to one of my problems mentioned, namely finding/querying
> data, interestingly only TTrees are discussed. For TTrees root has already
> powerful methods such as TChain, TCut, TEventList, but not all objects
> can be stored in trees or converted to trees. In general, an OODB should be
> able to handle all kinds of different objects.
> Suppose, I have many different objects stored in hierarchical form such
> as in TDirectory, TFolder or TDataSet. Furthermore, most of the variables
> of these objects are TString (e.g. TPerson has fFirstName, fLastName,
> fCity,..).
> How do you effectively query these objects?

Trees have no restrictions on the type of objects you can store. It is
perfectly legal to store strings, TString, char*, etc.
If you have a class member being one of these types, a branch will
be created for each type in split mode. For example, if you have
a class with members:
   TString  fName;
   char    *fDivision;
   char     fNation[12];
you can then query the Tree with
  tree.Draw("fName","fDivision == \"EP\"","bar2");

You can find examples in the new tutorial $ROOTSYS/tutorials/cernstaff.C

> 
> With respect to multiple users accessing the same TFile. As far as I
> understand TNetFile can be opened by multiple users in read mode but
> only by one user in update mode. It would be helpful if this behavior
> could be moved from TFile to TDirectory. This would allow multiple
> users to write to the same TFile but in different TDirectories only.
> 

The only way to implement multi write access is a client server model
with a data base server. The locking problem is solved simply by
queing the messages.
Implementing something at the TDirectory level will not change the
problem.

> Maybe a personal comment to Christian: If you (or someone else) intend
> to implement a query language for root, I would not implement SQL, but
> rather would try to implement the Object Query Language standard.

I have never seen a successfull use of OQL.

Rene Brun

> 
> Best regards
> Christian
> 
> Christian Holm Christensen wrote:
> 
> > Hi Rene,
> >
> > On Mon, 14 Jan 2002 21:45:12 +0100 (MET)
> > Rene Brun <brun@pcbrun.cern.ch> wrote
> > concerning "Re: [ROOT] TFolder or TDirectory?":
> > > OK, you simply want a translation mechanism from SQL format to TTree::Draw
> > > format. You can do this by extending TTreeFormula to support an SQL query.
> > > If you provide the function and test it on multiplatforms, I will
> > > include it in the source.
> >
> > It's quite a big endevour, 'cause you have to allow for things like
> >
> >   SELECT <member> FROM <branch> WHERE <expression>
> >   SELECT <branch1>.<member> FROM <branch1>,<branch2>
> >     WHERE <some expression envovling members of branch1 and branch2>
> >
> > not to mention
> >
> >   INSERT INTO <branch> (<member list) VALUES (<value list>)
> >   UPDATE TABLE <branch> SET <member>=<value>
> >
> > Ofcourse one can start with simle SELECTs, and just give errors in
> > other cases.  Anyway, I'm afraid it requires a lot of work, which I
> > can't do right now - sorry.  I did start something, but never got very
> > far, 'cause I realised just how much work it would take.  Perhaps at
> > some later point.
> >
> > 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:39 MET