New BRAT (2.1.8) - DB classes changed

From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Mon Oct 08 2001 - 08:49:45 EDT

  • Next message: Flemming Videbaek: "Re: New BRAT (2.1.8) - DB classes changed"

    Hi All, 
    
    I did a new minor version of BRAT: 
    
      Version: 2.1.8 
      CVS Tag: BRAT-2-1-8
    
    Please read the comments below.  Also if you do development, update
    your source tree ASAP, as some of these changes has impact through out
    the code.  It is therefor very important that your source tree is up
    to date before you commit anything to the CVS repository.  Thanks. 
    
    >From the ChangeLog 
    (made via Emacs - open file Makefile.am, and type C-x v a): 
    -----------------------------------------------------------
    
    2001-10-08  Christian Holm Christensen  <cholm@rcas0009.rcf.bnl.gov>
    
    	* configure.in: Bumped minor version
    
    	* test/.cvsignore: Added rotategeofile
    
    	* modules/util/BrMrsTofMatchingModule.cxx, modules/util/BrFfsTofMatchingModule.cxx, modules/util/BrDbUpdateModule.cxx, modules/util/BrDbCommitModule.cxx, modules/util/BrBfsTofMatchingModule.cxx, modules/rdo/BrZdcRdoModule.cxx, modules/rdo/BrTofRdoModule.h, modules/rdo/BrTofRdoModule.cxx, modules/rdo/BrTileRdoModule.cxx, modules/rdo/BrSiRdoModule.cxx, modules/rdo/BrChkvRdoModule.cxx, modules/rdo/BrBbCalHitsModule.cxx, modules/digitize/BrTileDigModule.cxx, modules/digitize/BrSiDigModule.cxx, modules/centrality/BrTileCentModule.cxx, modules/centrality/BrSiCentModule.cxx, modules/centrality/BrMultSdeCentModule.cxx, modules/centrality/BrMultCentModule.cxx, modules/calib/tof/BrTofTdcGainCalModule.cxx, modules/calib/tof/BrTofSlewingCalModule.cxx, modules/calib/tof/BrTofPedCalModule.cxx, modules/calib/tof/BrTofDeltaDelayCalModule.cxx, modules/calib/tof/BrTofCalModule.cxx, modules/calib/tof/BrTofAdcGainCalModule.cxx, modules/calib/dc/BrDcCalModule.cxx, modules/calib/chkv/BrChkvPedCalM!
    odule.cxx, modules/calib/chkv/BrChkvCalModule.cxx, modules/calib/bb/Makefile.am, modules/calib/bb/BrBbPedCalModule.cxx, modules/calib/bb/BrBbCalModule.cxx, managers/BrEventManager.cxx, db/apps/.cvsignore:
    	Changed to use new DB access classes
    
    	* db/test/TestRunsDb.cxx, db/test/.cvsignore: Minor changes
    
    	* db/run/Makefile.am, db/run/LinkDef.h, db/run/Include.h, db/run/BrRunsDb.h, db/run/BrRunsDb.cxx, db/run/BrRdbmRunsDb.h, db/run/BrRdbmRunsDb.cxx:
    	Implemented the polymorphic access approach.
    
    	* db/pass/Makefile.am, db/pass/LinkDef.h, db/pass/Include.h, db/pass/BrRootPassDb.h, db/pass/BrRootPassDb.cxx, db/pass/BrRdbmPassDb.h, db/pass/BrRdbmPassDb.cxx, db/pass/BrPassInfoManager.h, db/pass/BrPassInfoManager.cxx, db/pass/BrPassInfo.h, db/pass/BrPassInfo.cxx, db/pass/BrPassDb.h, db/pass/BrPassDb.cxx, db/pass/BrDbPass.h, db/pass/BrDbPass.cxx, db/pass/BrDbOutputFile.h, db/pass/BrDbOutputFile.cxx, db/pass/BrDbInputFile.h, db/pass/BrDbInputFile.cxx:
    	Reimplmented this DB interface to allow Polymorphic access.  This means
    	the at the class BrPassInfo and the corresponding manager
    	BrPassInfoManager is what the user sees, rather than the lowlevel
    	BrDbPass and so on.  Also, shortend some class names since they were
    	really long and didn't really add any information to the class. All
    	table representations are now prefixed with BrDb like in other database
    	access classes.
    
    	* db/main/Makefile.am, db/main/LinkDef.h, db/main/Include.h, db/main/BrRootMainDb.h, db/main/BrRootMainDb.cxx, db/main/BrRdbmMainDb.h, db/main/BrRdbmMainDb.cxx, db/main/BrMainDb.h, db/main/BrMainDb.cxx, db/main/BrDbSector.h, db/main/BrDbDetectorType.h, db/main/BrDbDetector.h, db/main/BrDbDb.h, db/main/BrDbDb.cxx, db/main/BrDbComponentType.h, db/main/BrDbComponent.h:
    	Added the pure table representation BrDbDb of BrahmsMain.DB, rather than
    	the misuse of BrDb.  Also added MySQL and ROOT implmentations of the
    	access.
    
    	* db/geometry/Makefile.am, db/geometry/LinkDef.h, db/geometry/Include.h, db/geometry/BrRdbmGeometriesDb.h, db/geometry/BrRdbmGeometriesDb.cxx, db/geometry/BrGeometriesDb.h, db/geometry/BrGeometriesDb.cxx, db/geometry/BrDbPlatformPosition.h, db/geometry/BrDbMagnetVolume.h, db/geometry/BrDbDetectorVolume.h:
    	Some small changes mostly (I'm not sure that Kris has finished this yet).
    	Implmented the MySQL implmentation of the BrGeometriesDb access class.
    	The ROOT implmentation must wait until it's clear what the status of this
    	part of BRAT is (I'm not all that happy with the current implmentation, and
    	it doesn't help not to have some documentation).
    
    	* db/calib/Makefile.am, db/calib/LinkDef.h, db/calib/Include.h, db/calib/BrRootCalibrationsDb.h, db/calib/BrRootCalibrationsDb.cxx, db/calib/BrRdbmCalibrationsDb.h, db/calib/BrRdbmCalibrationsDb.cxx, db/calib/BrDbRevisionType.h, db/calib/BrDbRevisionType.cxx, db/calib/BrDbRevision.h, db/calib/BrDbRevision.cxx, db/calib/BrDbParameter.h, db/calib/BrDbParameter.cxx, db/calib/BrCalibrationsDb.h, db/calib/BrCalibrationsDb.cxx, db/calib/BrCalibrationManager.h, db/calib/BrCalibrationManager.cxx, db/calib/BrCalibration.h, db/calib/BrCalibration.cxx:
    	* Renamed BrParameterElement[Manager] to BrCalibration[Manager]
    	* Impacts some modules, and maybe user code too.
    	* Made the access class BrCalibrationsDb 'polymorphic'
    	* All database table representations have class version > 0 (persistent)
    
    	* db/calib/BrParameterElementManager.h, db/calib/BrParameterElementManager.cxx, db/calib/BrParameterElement.h, db/calib/BrParameterElement.cxx:
    	Removed in favour of BrCalibration and BrCalibrationManager
    
    	* db/apps/Makefile.am, db/apps/DbUtils.h, db/apps/DbUtils.cxx, db/apps/CreateRun.cxx, db/apps/CreatePass.cxx, db/apps/CreateMain.cxx, db/apps/CreateGeometries.cxx, db/apps/CreateCalib.cxx:
    	Changed to use the new 'polymorphic' access classes. Also, DbUtils is now
    	a (static) class, rather than a set of functions.
    
    	* db/abc/Makefile.am, db/abc/LinkDef.h, db/abc/Include.h, db/abc/BrRootDb.h, db/abc/BrRootDb.cxx, db/abc/BrRdbmDb.h, db/abc/BrRdbmDb.cxx, db/abc/BrDbTable.h, db/abc/BrDbPerson.h, db/abc/BrDb.h, db/abc/BrDb.cxx:
    	Changed to allow polymorphic access classes.  The class BrDb defines the
    	interface, while BrRdbmDb and BrRootDb implements the interface.  Other
    	implmentations could be BrAsciiDb, BrObjyDb (shudder), BrXmlDb, and so on.
    	The table representation of the BrahmsMain.DB table has been moved from
    	BrDb to BrDbDb.
    
    	* data/calib/Makefile.am, data/calib/BrZdcCalibration.h, data/calib/BrZdcCalibration.cxx, data/calib/BrTofCalibration.h, data/calib/BrTofCalibration.cxx, data/calib/BrTileCalibration.h, data/calib/BrSiCalibration.h, data/calib/BrMultCentCalibration.h, data/calib/BrMultCentCalibration.cxx, data/calib/BrMultCalibration.h, data/calib/BrMultCalibration.cxx, data/calib/BrChkvCalibration.h, data/calib/BrChkvCalibration.cxx, data/calib/BrBbCalibration.h, data/calib/BrBbCalibration.cxx:
    	Changed detector calibration data classes to derive from BrCalibration,
    	rather than BrParameterElement, since that has been replaced. Impact
    	on various modules, and so on.  Some user code may need to be changed to.
    
    2001-10-05  Christian Holm Christensen  <cholm@rcas0009.rcf.bnl.gov>
    
    	* db/test/Makefile.am:
    	Added test of main and calibration database access
    
    	* db/test/TestMainDb.cxx: Added test of main database access
    
    	* db/test/TestCalibDb.cxx: Added test of calibration database access
    
    	* applications/misc/brconvnames:
    	Added script to convert names when class names are changed.
    
    	* applications/misc/Makefile.am: Added conversion script
    
    2001-10-05  Christian Holm Christensen  <cholm@rcas0009.rcf.bnl.gov>
    
    	* modules/calib/bb/BrPedsBB.h, modules/calib/bb/BrPedsBB.cxx, data/calib/BrCalibrationParamsTOF.h, data/calib/BrCalibrationParamsTOF.cxx, data/calib/BrCalibrationParamsBB.h, data/calib/BrCalibrationParamsBB.cxx:
    	Removed unused classes
    
    
    The thing to notice here, is the new implmentation classes for
    database access: 
    
    
    [Partial UML model diagram]
    
                                +----------+  +----------+
                                | BrRootDb |  | BrRdbmDb |  
                                +----------+  +----------+
                                      |             |
                                      +------+------+
                                             |
                                             V    
                           +------+    +-------------+
                           | BrDb 0----| BrVirtualDb |
    		       +------+    +-------------+ 
                              ^
                              |
               +--------------+---+------------+---------------+--- ...
               |                  |            |               |
      +------------------+  +----------+  +----------+  +----------------+
      | BrCalibrationsDb |  | BrMainDb |  | BrRunsDb |  | BrGeometriesDb |
      +------------------+  +----------+  +----------+  +----------------+
                                  ^
                                  |
                         +--------+--------+
                         |                 |
                  +--------------+  +--------------+
         ...      | BrRootMainDb |  | BrRdbmMainDb |     ...
                  +--------------+  +--------------+
    
      Legend:
      =======
      --->  Inherits from (is-a relationship)
      0---  Useses (has-a relationship)
      ...   More stuff like this 
    
    That is, we've now got the (truely) transparent interface class BrDb
    that defines the interface, and the abstract class BrVirtualDb that
    defines the interface a  given implmentation must conform to.  Two
    specialisation exits, one of general Releation DataBase Managers
    (BrRdbmDb) and one for ROOT file databases (BrRootDb).  
    
    What is really needed for ROOT files to be be 'true' RDBM, is the
    ability to do arbitriary SQL Queries on directories/arrays (in RDB
    lingo 'tables'). I believe it's feasible, but it'll take too long for
    me to implment. Perhaps that should be on a BRAHMS wishlist for the
    next ROOT user meeting (At CERN in Feburary I believe).  
    
    Note that one can access ROOT files via TCP/IP if the remote host is
    running the rootd daemon (see the directory rootd in ROOT source tree
    or look at the man(1) pages of rootd - done by yours truely :-). 
    
    Please note, that the ROOT db file stuff is not fully tested, but the
    general principle holds.  Believe is what we'd like to be able to do
    with ROOT files.  So feel free to try and make it work (I'll happily
    answer questions on that).  The below comments are for easier
    startup. 
     
    Per default, the databases used are the Rdbm variants.  If one wants
    to select, say a ROOT file for temporary access, one would do in a
    bratmain configuration script:
    
      BrCalibrationsDb* calibDb = BrRootCalibrationsDb::Instance(); 
      calibDb->SetHostName("some.where.edu"); 
      calibDb->SetDbName("~someone/tempdb/calib.root"); 
    
      BrMainDb* mainDb = BrMainDb::Instance();
      mainDb->SetDbName(maindbNameOption->GetValue()); 
      mainDb->SetHostName(maindbHostOption->GetValue()); 
      mainDb->SetUserName(maindbUserOption->GetValue()); 
    
      if (!mainDb->ConnectToCalib()) 
        return;
    
      if (!mainDb->ConnectToRun()) 
        return;
    
      if (!mainDb->ConnectToPass()) 
        return;
    
      if (!mainDb->ConnectToGeometry()) 
        return;
    
    Note that the above assumes that BrMainDb will not try to modify a
    BrDb object if it's attributes has already been set (not implmented). 
    
    The above assumes that you have the file 
    
      some.where.edu:~someone/tempdb/calib.root 
    
    which contains all the 'tables' usualy found in the calibration
    database.  One can easily implment a small script that takes the stuff
    from the canonical database and puts it in a ROOT file, thereby making
    sure all IDs are consistent.  I leave it as an exercise to the
    intrested reader :-) 
    
    The above code will use the ROOT file for all parameters of all
    classes.  If one wants to use the regular database for most detectors,
    but a few detectors wants to use a temporary database (say for
    checking a calibration), one does a normal connection to the database: 
    
      BrMainDb* mainDb = BrMainDb::Instance();
      mainDb->SetDbName(maindbNameOption->GetValue()); 
      mainDb->SetHostName(maindbHostOption->GetValue()); 
      mainDb->SetUserName(maindbUserOption->GetValue()); 
    
      if (!mainDb->ConnectToCalib()) 
        return;
    
      if (!mainDb->ConnectToRun()) 
        return;
    
      if (!mainDb->ConnectToPass()) 
        return;
    
      if (!mainDb->ConnectToGeometry()) 
        return;
    
    and then somewhere before BrCalibrationManager::Init() (this class
    used to be called BrParamaterElementManager) one has (assuming we're
    talking about TOF1): 
    
      BrCalibrationManager* calibMan = BrCalibrationManager::Instance();
      BrTofCalibration* tof1Calib = (BrTofCalibration*)
        calibMan->Register("BrTofCalibration", "TOF1"); 
       
    Now to select the ROOT file as the database to use, one need to do,
    again before BrCalibrationManager::Init(): 
    
      BrCalibrationsDb* calibDb = 
        new BrRootCalibrationsDb("CalibDb", ""); 
      calibDb->SetHostName("some.where.edu"); 
      calibDb->SetDbName("~someone/tempdb/calib.root"); 
      tof1Calib->SetDatabase(calibDb); 
    
    This needs to be done after the BrCalibrationManager::Register, but
    before BrCalibrationManager::Init() - which means we probably need
    some sort of module for that. 
    
    Note that this new scheme is very flexible - one can implement various
    backends, for example a backend that deals with XML formated files
    like 
    
       <Parameter id=15 name="pedestal" detector=10 type="Float_t" ...>
       <Revision id=104 reference=15 start=1000000000 stop=1000000100 
          blobsize=10 ...>
         <element>3.2093488209814</element> 
         <element>1.2323789235</element> 
         ...
       </Revision> 
    
    and so on. 
      
    Note, that I had to change the Pass DB access rather a lot to fit into
    this scheme (and the general BRAT design).  I introduced the managed
    class BrPassInfo (manager BrPassInfoManager), and the classes
    BrDbPass, BrDbInputFile, and BrDbOutputFile are now one-to-one
    representations of table entries.  The design is parallel to the one
    of BrRunInfo and BrRunInfoManager.  Note, that the Pass database is
    really only useful, if we implement our own job scheduler for CRS
    (which I think is a bloody waste of time by the way), or if we can
    have shared remote memory (something that Linux is not too good at -
    MACH is much better at it I believe). 
    
    As you can see from the above, a number of class names have
    changed. To help you with porting your code to use the new names, I've
    added the script applications/misc/brconvnames (installed in
    <prefix>/bin).  The intention is to have this script evolve to do
    replacements of class names when ever they are changed.  Do a
    brconvnames --help to get some help on options and input. 
    
    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 2b30 : Mon Oct 08 2001 - 08:50:04 EDT