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:38 MET