Recommended solutions for common subsystem coordinator's tasks reside here.
Please check pages below.
It is required to
a) initialize Offline database for each subsystem just before new Run,
..and..
b) put "closing" entry at the end of the "current" Run;
To make life easier, there is a script which takes database entry from specified time, and re-inserts it at desired time. Here it is:
void table_reupload(const char* fDbName = 0, const char* fTableName = 0, const char* fFlavorName = "ofl",
const char* fRequestTimestamp = "2011-01-01 00:00:00",
const char* fStoreTimestamp = "2012-01-01 00:00:00" ) {
// real-life example :
// fDbName = "Calibrations_tpc";
// fTableName = "tpcGas";
// fFlavorName = "ofl"; // "ofl", "simu", other..
// fRequestTimestamp = "2010-05-05 00:00:00";
// fStoreTimestamp = "2011-05-05 00:00:00";
if (!fDbName || !fTableName || !fFlavorName || !fRequestTimestamp || ! fStoreTimestamp) {
std::cerr << "ERROR: Missing initialization data, please check input parameters!\n";
return;
}
gSystem->Setenv("DB_ACCESS_MODE", "write");
// Load all required libraries
gROOT->Macro("LoadLogger.C");
gSystem->Load("St_base.so");
gSystem->Load("libStDb_Tables.so");
gSystem->Load("StDbLib.so");
// Initialize db manager
StDbManager* mgr = StDbManager::Instance();
mgr->setVerbose(true);
StDbConfigNode* node = mgr->initConfig(fDbName);
StDbTable* dbtable = node->addDbTable(fTableName);
//dbtable->setFlavor(fFlavorName);
// read data for specific timestamp
mgr->setRequestTime(fRequestTimestamp);
std::cout << "Data will be fetched as of [ " << mgr->getDateRequestTime() << " ] / "<< mgr->getUnixRequestTime() <<" \n";
mgr->fetchDbTable(dbtable);
// output results
std::cout << "READ CHECK: " << dbtable->printCstructName() << " has data: " << (dbtable->hasData() ? "yes" : "no") << " (" << dbtable->GetNRows() << " rows)" << std::endl;
if (!dbtable->hasData()) {
std::cout << "ERROR: This table has no data to reupload. Please try some other timestamp!";
return;
} else {
std::cout << "Data validity range, from [ " << dbtable->getBeginDateTime() << " - " << dbtable->getEndDateTime() << "] \n";
}
char confirm[255];
std::string test_cnf;
std::cout << "ATTENTION: please confirm that you want to reupload " << fDbName << " / " << fTableName << ", " << fRequestTimestamp << " data with " << fStoreTimestamp << " timestamp.\n Type YES to proceed: ";
std::cin.getline(confirm,256);
test_cnf = confirm;
if (test_cnf != "YES") {
std::cout << "since you've typed \"" << test_cnf << "\" and not \"YES\", data won't be reuploaded." << std::endl;
return;
}
// store data back with new timestamp
if (dbtable->hasData()) {
mgr->setStoreTime(fStoreTimestamp);
if (mgr->storeDbTable(dbtable)) {
std::cout << "SUCCESS: Data reupload complete for " << fDbName << " / " << fTableName << " [ flavor : " << fFlavorName << " ]"
<< "\n" << "Data copied FROM " << fRequestTimestamp << " TO " << fStoreTimestamp << std::endl << std::endl;
} else {
std::cerr << "ERROR: Something went wrong. Please send error message text to DB Admin!" << std::endl;
}
}
}There are three primary database types in STAR: Online databases, Offline databases and FileCatalog. FileCatalog database is solely managed by STAR S&C, so subsystem coordinators should focus on Online and Offline databases only.
Online database is dedicated to subsystem detector metadata, collected during the Run. For example, it may contain voltages, currents, error codes, gas meter readings or something like this, recorded every 1-5 minutes during the Run. Or, it may serve as a container for derived data, like online calibration results.
Online db metadata are migrated to Offline db for further usage in STAR data production. Major difference between Online and Offline is the fact that Online db is optimized for fast writes, and Offline is optimized for fast reads to achieve reasonable production times. Important: each db type has its own format (Offline is much more constrained).
Offline database contains extracts from Online database, used strictly as accompanying metadata for STAR data production purposes. This metadata should be preprocessed for easy consumption by production Makers, thus it may not contain anything involving complex operations on every data access.
o) Please don't plan your own database internal schema. In a long run, it won't be easy to maintain custom setup, therefore, please check possible options with STAR db administrator ASAP.
o) Please decide on what exactly you want to keep track of in Online domain. STAR DB administrator will help you with data formats and optimal ways to store and access that data, but you need to define a set of things to be stored in database. For example, if your subsystem is connected to Slow Controls system (EPICS), all you need is to pass desired channel names to db admistrator to get access to this data via various www access methods (dbPlots, RunLog etc..).
o) ...
o) ...