Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • v5-34-00-patches
  • v6-26-00-patches
  • v6-28-00-patches
  • v6-22-00-patches
  • v6-24-00-patches
  • latest-stable
  • v6-18-00-patches
  • v6-20-00-patches
  • v6-16-00-patches
  • v6-14-00-patches
  • v6-12-00-patches
  • v6-10-00-patches
  • v6-06-00-patches
  • v6-08-00-patches
  • v6-28-02
  • v6-28-00
  • v6-28-00-rc1
  • v6-29-01
  • v6-27-02
  • v6-26-10
  • v6-26-08
  • v6-24-08
  • v6-26-06
  • v6-26-04
  • v6-26-02
  • v6-26-00
  • v6-25-02
  • v6-24-06
  • v6-24-04
  • v6-24-02
  • v6-24-00
  • v6-22-08
  • v6-25-01
  • v6-24-00-rc1
35 results
Search by author
  • Any Author
  • Xu Chen Xu Chen chenxu
1 author
  1. Nov 24, 2005
  3. Nov 23, 2005
  5. Nov 22, 2005
  7. Nov 21, 2005
    • Fons Rademakers's avatar
      correct case of multiple inclusion protection define. · 06e6f991
      Fons Rademakers authored 
      git-svn-id: http://root.cern.ch/svn/root/trunk@13313 27541ba8-7e3a-0410-8455-c3a389f83636
      06e6f991
    • Philippe Canal's avatar
      From Sergey: · 6b861d0c
      Philippe Canal authored 
      Introduce a "transparent" access to SQL data base via standard TFile interface.

The main approach that each class (but not each object) has one or two tables
with names like $(CLASSNAME)_ver$(VERSION) and $(CLASSNAME)_streamer_ver$(VERSION)
For example: TAxis_ver8 or TList_streamer_ver5
Second kind of tables appears, when some of class members can not be converted to
normalized form or when class has custom streamer.
For instance, for TH1 class two tables are required: TH1_ver4 and TH1_streamer_ver4
Most of memebers are stored in TH1_ver4 table columnwise, and only memeber:

Double_t*  fBuffer;  //[fBufferSize]

can not be represented as column while size of array is not known apriory.
Therefore, fBuffer will be written as list of values in TH1_streamer_ver4 table.

All objects, stored in the DB, will be registered in table "ObjectsTable".
In this there are following columns:
"key:id"  - key identifier to which belong object
"obj:id"  - object identifier
"Class"   - object class name
"Version" - object class version
Data in each "ObjectsTable" row uniqly identify, in which table
and which column object is stored.

In normal situation all class data should be sorted columnwise.
Up to now following member are supported:
1) Basic data types
Here is everything clear. Column SQL type will be as much as possible
close to the original type of value.
2) Fixed array of basic data types
In this case n columns like fArr[0], fArr[1] and so on will be created.
If there is multidimensional array, names will be fArr2[1][2][1] and so on
3) Parent class
In this case version of parent class is stored and
data of parent class will be stored with the same obj:id in corrspondent table.
There is a special case, when parent store nothing (this is for instance TQObject).
In that case just -1 is written to avoid any extra checks if table exist or not.
4) Object as data member.
In that case object is saved in normal way to data base and column
will contain id of this object.
5) Pointer on object
Same as before. In case if object was already stored, just its id
will be placed in the column. For NULL pointer 0 is used.
6) TString
Now column with limited width like VARCAHR(255) in MySQL is used.
Later this will be improved to support maximum possible strings
7) Anything else.
Data will be converted to raw format and saved in _streamer_ table.
Each row supplied with obj:id and row:id, where row:id indicates
data, corresponding to this particular data member, and column
will contain this raw:id

See the TSQLFile documentation for more details.

example of a session saving data to a SQL data base
=====================================================

const char* dbname = "mysql://host.domain:3306/dbname";
const char* username = "username";
const char* userpass = "userpass";

// Clean data base and create primary tables
TSQLFile* f = new TSQLFile(dbname, "recreate", username, userpass);
// Write with standard I/O functions
arr->Write("arr",TObject::kSingleKey);
h1->Write("histo");
// Close connection to DB
delete f;

example of a session read data from SQL data base
=====================================================

// Open database again in read-only mode
TSQLFile* f = new TSQLFile(dbname, "open", username, userpass);
// Show list of keys
f->ls();
// Read stored object, again standard ROOT I/O
TH1* h1 = (TH1*) f->Get("histo");
if (h1!=0) { h1->SetDirectory(0); h1->Draw(); }
TObject* obj = f->Get("arr");
if (obj!=0) obj->Print("*");
// close connection to DB
delete f;

Known problems and open questions.
1) TTree is not supported by TSQLFile. There is independent development
of TTreeSQL, which allows to store trees directly in SQL database
2) TClonesArray is not tested, will be adjusted soon.
3) TDirectory cannot work. Hopefully, will (changes in ROOT basic I/O is required)
4) Streamer infos are not written to file, therefore schema evolution
is not yet supported. All eforts are done to enable this feature in
the near future


git-svn-id: http://root.cern.ch/svn/root/trunk@13312 27541ba8-7e3a-0410-8455-c3a389f83636
      6b861d0c
    • Philippe Canal's avatar
      From Sergey: · 3c301dc0
      Philippe Canal authored 
      Introduce a "transparent" access to SQL data base via standard TFile interface.

The main approach that each class (but not each object) has one or two tables
with names like $(CLASSNAME)_ver$(VERSION) and $(CLASSNAME)_streamer_ver$(VERSION)
For example: TAxis_ver8 or TList_streamer_ver5
Second kind of tables appears, when some of class members can not be converted to
normalized form or when class has custom streamer.
For instance, for TH1 class two tables are required: TH1_ver4 and TH1_streamer_ver4
Most of memebers are stored in TH1_ver4 table columnwise, and only memeber:

Double_t*  fBuffer;  //[fBufferSize]

can not be represented as column while size of array is not known apriory.
Therefore, fBuffer will be written as list of values in TH1_streamer_ver4 table.

All objects, stored in the DB, will be registered in table "ObjectsTable".
In this there are following columns:
    "key:id"  - key identifier to which belong object
    "obj:id"  - object identifier
    "Class"   - object class name
    "Version" - object class version
Data in each "ObjectsTable" row uniqly identify, in which table
and which column object is stored.

In normal situation all class data should be sorted columnwise.
Up to now following member are supported:
  1) Basic data types
     Here is everything clear. Column SQL type will be as much as possible
     close to the original type of value.
 2) Fixed array of basic data types
     In this case n columns like fArr[0], fArr[1] and so on will be created.
     If there is multidimensional array, names will be fArr2[1][2][1] and so on
 3) Parent class
     In this case version of parent class is stored and
     data of parent class will be stored with the same obj:id in corrspondent table.
     There is a special case, when parent store nothing (this is for instance TQObject).
     In that case just -1 is written to avoid any extra checks if table exist or not.
 4) Object as data member.
     In that case object is saved in normal way to data base and column
     will contain id of this object.
 5) Pointer on object
     Same as before. In case if object was already stored, just its id
     will be placed in the column. For NULL pointer 0 is used.
 6) TString
     Now column with limited width like VARCAHR(255) in MySQL is used.
     Later this will be improved to support maximum possible strings
 7) Anything else.
     Data will be converted to raw format and saved in _streamer_ table.
     Each row supplied with obj:id and row:id, where row:id indicates
     data, corresponding to this particular data member, and column
     will contain this raw:id

See the TSQLFile documentation for more details.

 example of a session saving data to a SQL data base
 =====================================================

  const char* dbname = "mysql://host.domain:3306/dbname";
  const char* username = "username";
  const char* userpass = "userpass";

  // Clean data base and create primary tables
  TSQLFile* f = new TSQLFile(dbname, "recreate", username, userpass);
  // Write with standard I/O functions
  arr->Write("arr",TObject::kSingleKey);
  h1->Write("histo");
  // Close connection to DB
  delete f;

 example of a session read data from SQL data base
 =====================================================

  // Open database again in read-only mode
  TSQLFile* f = new TSQLFile(dbname, "open", username, userpass);
  // Show list of keys
  f->ls();
  // Read stored object, again standard ROOT I/O
  TH1* h1 = (TH1*) f->Get("histo");
  if (h1!=0) { h1->SetDirectory(0); h1->Draw(); }
  TObject* obj = f->Get("arr");
  if (obj!=0) obj->Print("*");
  // close connection to DB
  delete f;

Known problems and open questions.
 1) TTree is not supported by TSQLFile. There is independent development
    of TTreeSQL, which allows to store trees directly in SQL database
 2) TClonesArray is not tested, will be adjusted soon.
 3) TDirectory cannot work. Hopefully, will (changes in ROOT basic I/O is required)
 4) Streamer infos are not written to file, therefore schema evolution
    is not yet supported. All eforts are done to enable this feature in
    the near future


git-svn-id: http://root.cern.ch/svn/root/trunk@13311 27541ba8-7e3a-0410-8455-c3a389f83636
      3c301dc0
    • Olivier Couet's avatar
      - Mods for the rules checker · b6f9a333
      Olivier Couet authored 
      git-svn-id: http://root.cern.ch/svn/root/trunk@13310 27541ba8-7e3a-0410-8455-c3a389f83636
      b6f9a333
    • Stefan Roiser's avatar
      From Pere: · a6d0739b
      Stefan Roiser authored 
      * added new header file NewDelFunctions.h in Build section
* CollectionProxy.h:  Fixed problem compiling hash_multimap stuff with


git-svn-id: http://root.cern.ch/svn/root/trunk@13309 27541ba8-7e3a-0410-8455-c3a389f83636
      a6d0739b
    • Stefan Roiser's avatar
      From Pere: · 4107a7f3
      Stefan Roiser authored 
      * Fixed new and delete of arrays. Makes use of the extra (artificial) function __getNewDelFunctions()
* Fixed free functions in namespaces when loding the dictionary before enabling Cintex


git-svn-id: http://root.cern.ch/svn/root/trunk@13308 27541ba8-7e3a-0410-8455-c3a389f83636
      4107a7f3
    • Stefan Roiser's avatar
      fixing ambigous operator · 39824493
      Stefan Roiser authored 
      git-svn-id: http://root.cern.ch/svn/root/trunk@13307 27541ba8-7e3a-0410-8455-c3a389f83636
      39824493
    • Rene Brun's avatar
      From Ilka: · 0e90235e
      Rene Brun authored 
      allow the TH2Editor editor to be activated for empty histograms (check for a histogram
name 'htemp', not for the number of entries = 0, as a condition to avoid empry
histograms used for ntuple drawings).


git-svn-id: http://root.cern.ch/svn/root/trunk@13306 27541ba8-7e3a-0410-8455-c3a389f83636
      0e90235e
    • Stefan Roiser's avatar
      Introducing new functions Base::ToScope, Type::operator Scope · f12abd7d
      Stefan Roiser authored 
      Bugfix ScopeBase::ScopeTypeAsString: return also valid values for Enums and Unions


git-svn-id: http://root.cern.ch/svn/root/trunk@13305 27541ba8-7e3a-0410-8455-c3a389f83636
      f12abd7d
    • Olivier Couet's avatar
      - Last mods (in graf) to make the rules checker happy. · fb544230
      Olivier Couet authored 
      git-svn-id: http://root.cern.ch/svn/root/trunk@13304 27541ba8-7e3a-0410-8455-c3a389f83636
      fb544230