Minos DBI General Status Nick West

1. Minos DBI General StatusNick West Contents • Recall: The placeholder strategy and the services it provides • Current deployment • Long term use: Our requirements, problems with MinosDBI Two Day Face-to-Face Meeting

2. Recall: Placeholder Strategy • Placeholder strategy: Short term hack matching long term API • Thin wrapper package: oaOfflineDatabase • Implementation package: MinosDBI oaOfflineDatabase MinosDBI DatabaseInterface: Database API Record: Foundation record services Configurable: Package configuration Validity: Validity context Conventions: Naming conventions LeakChecker: Simpleleak checker Registry: A key value set Util: Data utilities MessageService: Message management ROOT: TSQL Two Day Face-to-Face Meeting

3. Recall: The Services It Provides Read Access • Example TFB calibration table: DEMO_CALIB_TABLE4 columns: CHANNEL_ID int, I_PARM int, F_PARM float, S_PARM text • Must develop corresponding table row class class TDemo_Calib_Table : public TTableRow { public: TTfbChannelId GetId() const; Int_t GetIparm() const { return fIparm; } Float_t GetFparm() const { return fFparm; } string GetSparm() const { return fSparm; } void Print(); ... }; • The Query: For event context return handle to a vector of TDemo_Calib_Table rowsTND280Event event; ND::TResultSetHandle<ND::TDemo_Calib_Table> rsh(event.GetContext()); • Sequential Access GetRow(int index) e.g. Iterate over all rowsfor (Int_t irow = 0; irow < rs.GetNumRows(); ++irow) rs.GetRow(irow)->Print(); • Random Access GetRowByIndex(int index) e.g. For given TFB return corresponding rowND::TTfbChannelId id;const ND::TDemo_Calib_Table* row = rs.GetRowByIndex(id);if ( row ) row->Print();else ND280Log("bother!"); Two Day Face-to-Face Meeting

4. Recall: The Services It Provides: Memory Management Aggregation: Natural Structuring of Data • Memory Management • TRseultSetHandle is a lightweight handle • Can copy, pass by value etc. • DBI retains heavyweight result set • At least until all handles destroyed • Aggregation • A result set represents entire detector • But detector granular (sub-detectors) • No reason why all rows have same validity: some may be more volatile than others • Solution: Form “aggregates” • All rows sharing a validity are aggregated together • First column of row is an integer SEQNO • Members of aggregate have same value of SEQNO • SEQNO keys to a single row in separate table that holds the validity • The interface hides this structuring • For the supplied context it locates all aggregates • Presents as single “seamless” table Two Day Face-to-Face Meeting

5. Current Deployment Two Day Face-to-Face Meeting

6. Long Term Use: What are our requirements ? • Someone is bound to ask: “Can we use the MinosDBI in the long term?” • But before we can finalise on any implementation we need to analyse our requirements • If this has already been done than I have missed it! • What backends? • MySQL of course, but others? Postgres, Oracle, Sybase ... • What is our distribution model? • Not one database for entire collaboration • Too slow and too fragile • Could have single Master feeding a series of Slaves using MySQL replication • What if we want multiple Masters? • What types of data? • Possiblities: beam spill, slow controls, calibration, book-keeping • Each has a different volatility • Do we support unsigned integer data? • MINOS DBI doesn’t (but did until we tried to support Oracle backend) • What defines "Context" besides date and time? • Possibilities: run, type (real/MC), sub-detector • How do we resolve overlaps to get "best" rows? • Overlaps are essential for calibration – cannot afford to have gaps! • What types of query are required? • Of course “best data for this context” • What about others e.g. all data in a time window, multiple table queries. • Reproducing the past • Do we support local roll-back to reproduce past results? • How do we support global roll-back for past recalibration passes? • How do we support trial table updates ? • Must be able to privately test out new data Two Day Face-to-Face Meeting

7. Problems with MinosDBI • What if MinosDBI is shown to be a good fit to T2K requirements? • Should we keep it then? • No! At least not in its current form • Code is far too dirty: drags in 8 other MINOS packages • Some could be removed e.g. leak checker • Some could be replaced e.g. logger • But others are essential e.g. Validity, Registry • Has (at least) two serious flaws • Creation Date used for two conflicting purposes • Validity table should support additional columns • There could be others • Other experiments (SNO+, Daya Bay and Double Chooz) are either using, or have considered using, the MINOS code • I can ask them what else they found. • In any case I have not discussed any of this with Iain Bertram • I don't know haw far his plans have developed. Two Day Face-to-Face Meeting