Re: [ROOT] TFolder or TDirectory?

From: cstrato@EUnet.at
Date: Sat Jan 19 2002 - 21:15:28 MET


Rene Brun wrote:

> 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.

Dear Rene, your are completely right, and such an implementation of a class
TTransaction is way beyond my intention, my abilities and my possibilities.
It simply turned out that the concept behind a transaction fits my purposes.

>
>
> >
> > 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

Thank you for this short example, I am aware of this possibility and
originally intended to store my objects in a TTree.
However, consider the following problem: In my GUI I have TTreeView,
which displays the hierarchy in TFile. When I click on a TDirectory or
TFolder, the contents of the objects stored are immediately displayed
on the right side. Since hierarchies and the objects therein will be constantly
added/deleted, I could not see how I can use TTrees to store the objects.

>
>
> >
> > 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.

The same can probably be said about OODBs in general, but I am not
competent enough to discuss this issue. It is simply my feeling that
root has the potential to become the first successful OODB (although
I understand that it is currently not a high priority).

Best regards
Christian

>
>
> Rene Brun



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:39 MET