Star Database Tutorial Package Design & Objectivity Discussion Interface Questions – What do you want? -> making requests – What do you get? -> data container – How to add a new object type? -> definition protocols – How do you update? -> db input protocols

Objectivity: OODB w/ C++ API Is a Database –Persistency Mechanism –Concurrency & Locking Mechanisms –Access by Query on predefined fields –Fast search over large data samples

Objectivity: OODB w/ C++ API Is an OO Database –Provides Direct Navigation tools to data –Gives OO methodology to persistent data But … –Direct Navigation was attractive for Event-Store –Persistent-to-Transient copy allows adding OO methodology at copy level

Conditions DB Description Database of the experimental conditions. Database Access –Updates are predominantly done from Online –Storage & retrieval by timestamp Update Frequency –pre-determined updates (e.g. ~hourly snap-shot) –alarm-activated updates (at level of individual object) Data Volume –moderate per update (~Mbyte) –moderately large in aggregate (>~Gbytes)

Star-BaBar Conditions DB Is applied to each Subsystem (e.g. tpc, svt,..) conditions/subsystem/UniqueObjects conditions/subsystem/Index-to-Objects e.g. TPCVoltages & Sector_01Voltages represent unique (& uniquely named) object types stored in the “conditions/tpc/databases” & accessed via “conditions/tpc/IndexDB”

Conditions-like Star DBs Access by time-stamp & subsystem conditions/subsystem configurations/subsystem calibrations/subsystem geometry/subsystem

Interface Questions What do you want? - making requests What do you get? - data container How to add new object type? - definition protocols How do you update? - db input protocols

1) What do you want? Offline data is organized in Tree-Structure good idea - Online likes this too. Database-API Tree is shallow (2-levels) map to Tree structure at data access Database access is request & retrieve process BdbDatabase->fetch(ObjH,indexContainer,theTime); Codes need to know what to request at object level

Current Offline Model Objects are files in Tree-like file-system file-system = catalog of available objects $STAR/StDb/params/tpc/trspar/Trs.C A time-stamp in the filename for each instance myobject.time.C or myobject.time.xdf Upon request, all valid data in Tree is loaded other Makers get data from memory resident Tree

Offline Interface Model St_DataSet* ds = GetDataBase(subtree-name); loads Tree-structure under “subtree-name” into db memory mdbds = ds->Find(specific-name); gives St_A_Maker pointer to specific db data

DB Interface Model StdbPtr* mdbo = factoryI->getdbObject(name, time, version);

DB Interface Model issue How does St_db_Maker know what to load? 1) StdbCatalogI* mycat = factoryI->getCatalog(); Catalog is Tree-Structured container of all available objects for this dbType. 2) StdbCatalogI* mycat = new StdbCatalog(“file”); “file” contains Tree-Structured container of objects as filtered for a specific “Chain”.

DB Catalog Structure Geometry tpc TPCPadPlanes Sector_01 sectorPosition Sector_02 sectorPositions V02 ObjyObjectName = tpcSector_01sectorPositions

A Related Interface Issue How does St_db_Maker know to load my private test version of DB-data? factoryI->prependSearchPath(“pathname”); 1) Factory will use your path 1st to access db-data. 2) Data must be in “the standard” format & Tree 3) St_db_Maker needs to call this function; Not You.

2) What do you get?

DB Return-type: StdbPtr Transient DB objects inherit from StdbPtr. StdbPtr contains a (list of) pointer to StdbObjectI. StdbObjectI defines methods: getName(), getVersion(), getEndTime(),... StdbPtr uses StdbObjectI to provide method : bool isValid(time,version); St_DbSet (like St_ObjectSet) inherits from St_DataSet & contains StdbPtr*.

What does this mean to you? Remember, we had St_DataSet* ds = GetDataBase(subtree-name); loads Tree-structure under “subtree-name” into db memory mdbds = ds->Find(specific-name); mdb_table = (my_table*) mdbds->GetTable(); gives St_A_Maker pointer to specific db data Now we have, St_DataSet* ds = GetDataBase(subtree-name); loads Tree-structure under “subtree-name” into db memory mdbds = ds->Find(specific-name); mdbObj = (DataObject *)mdbds->GetdbObject(); gives St_A_Maker pointer to specific db data

Transient-Persistent Mismatch Efficient data storage suggests grouping data by function & update frequency. This organization can be different than what user codes want. Who does copying from persistent structure to desirable transient structure? If Offline: persistent -> transient -> better transient If DBInterface: persistent -> better transient

Basic Model DB returns data; Offl repacks into trans-DS : Case: UI-Object =>dbStuctA + dbStructB + … StdbPtr* mdbA = factoryI->getdbObject(“A”, time, version); StdbPtr* mdbB = factoryI->getdbObject(“B”, time, version); …. StDataObject* mUI = new StDataObject(mdbA, mdbB, ….); mDataSet->AddObject(mUI); if(mdbA) delete mdbA; if(mdbB) delete mdbB; …. St_db_Maker has to know about Data Objects DB does not.

Alternative Model (“in use”) DB returns filled UI-Object as requested StdbPtr* mUI = factoryI->getdbObject(name, time,version); mDataSet->AddObject(mUI); DB (& Catalog) has to know about Data Objects St_db_Maker does not. In the end, it should be done somewhere AND it shouldn’t matter to user codes.

3) How to add a new data type? Join starcalib-l & meetings The process is not Templated yet…. Also look at some current examples $STAR_DB/DataBases/preStDb/Calib/... $STAR/StDb/params/… ($STAR_DB is not on AFS but on rcf )

in particular... Work with calib/database group to add to Database. Define the data members needed typically one or more c-structs Define the UI object that is needed may be a simple table… may be more complex Define a class that implements UI & contains the data.

4) How to update db-data? Protocols haven’t been defined. There will be some access restrictions on updates like Online authorization modes or CVS Private output via ROOT or XDF files + migration step into the Database is a likely general solution.