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