My code is checked out here: file:///usera/sctrod/lester/TDAQ20/SctRodDaq/SCT/COOL_Test
The SCT/[CoolTools] makes heavy use of COOL. See also the CoolTools page of this wiki.
Links
[Giovanna's is2cool_archive code]
The [Cool] web page and the [COOL software in CVS].
This is the [COOL explained simply on the ATLAS COOL Twiki page].
Note explaining [how to develop without needing to use a database] but using a file instead by using SQLite. Roughly:
The SQLite option implements a complete relational database in a single local file, which may be particularly attractive for individual users developing calibration algorithms or data, which can then be migrated to the central Oracle infrastructure. To use an SQlite database, the connection string is of the form: IOVDbSvc.dbConnection="impl=cool;techno=sqlite;schema=mysqlfile.db;DUMMY:COOLTEST" which establishes a connection to the COOL database COOLTEST resident in the file mysqlfile.db (which must be writeable). If the file does not exist, it is created as an empty database. Since the database is just a file, and permissions are handled by the file system, no server name, username or password are required (so the username and password fields in the connection string are missing, but a DYMMY server name must be given to satisfy IOVDbSvc? - the actual value used is ignored).
A few ["getting started"] examples can be found on the [CoolAthena] Twiki page.
[Best examples] are linked from [the hard to find COOL documentaion pages] linked from the "snapshot" headings on the [LCG applications doxygen page].
All about [Connection Strings].
Notes regarding use of sqlite
There seem to be some system libraries for sqlite .. eg
/usr/lib/libsqlite3.so.0 /usr/lib/libsqlite3.so.0.8.6
which although supposedly the same version as the LCG ones cause almost any use of sqlite via cool to result in a message like "Bad syntax NOT in query blah". To get around this it is necessary to make the SctDaq? SW_Repository depend on a SW_ExternalPackage as below (via the SW_Rep's "Uses" relation). Note that the only real effect this has is adding some extra lines the the LD_LIBRARY_PATH of the executables in the SW_Repository. Such paths are built out of the supplied "InstallationPath?" followed by snippets taken from the TagMapping? objects.
<obj class="SW_ExternalPackage" id="SCT_SQLITE">
<attr name="Name" type="string">"CMT external package SQLITE"</attr>
<attr name="InstallationPath" type="string">"${LCG_INST_PATH}/external/sqlite/3.4.0"</attr>
<rel name="Uses" num="0"></rel>
<rel name="ProcessEnvironment" num="0"></rel>
<rel name="AddProcessEnvironment" num="0"></rel>
<rel name="Binaries" num="9">
"TagMapping" "i686-slc4-gcc34-dbg-for-slc4_ia32_gcc34/bin"
"TagMapping" "i686-slc4-gcc34-dbg-for-slc4_ia32_gcc34/bin"
"TagMapping" "i686-slc4-gcc34-dbg-for-slc4_ia32_gcc34/bin"
"TagMapping" "i686-slc4-gcc34-opt-for-slc4_ia32_gcc34/bin"
"TagMapping" "i686-slc4-gcc34-opt-for-slc4_ia32_gcc34/bin"
"TagMapping" "x86_64-slc4-gcc34-dbg-for-slc4_amd64_gcc34/bin"
"TagMapping" "x86_64-slc4-gcc34-dbg-for-slc4_amd64_gcc34/bin"
"TagMapping" "x86_64-slc4-gcc34-opt-for-slc4_amd64_gcc34/bin"
"TagMapping" "x86_64-slc4-gcc34-opt-for-slc4_amd64_gcc34/bin"
</rel>
<rel name="SharedLibraries" num="9">
"TagMapping" "i686-slc4-gcc34-dbg-for-slc4_ia32_gcc34/lib"
"TagMapping" "i686-slc4-gcc34-dbg-for-slc4_ia32_gcc34/lib"
"TagMapping" "i686-slc4-gcc34-dbg-for-slc4_ia32_gcc34/lib"
"TagMapping" "i686-slc4-gcc34-opt-for-slc4_ia32_gcc34/lib"
"TagMapping" "i686-slc4-gcc34-opt-for-slc4_ia32_gcc34/lib"
"TagMapping" "x86_64-slc4-gcc34-dbg-for-slc4_amd64_gcc34/lib"
"TagMapping" "x86_64-slc4-gcc34-dbg-for-slc4_amd64_gcc34/lib"
"TagMapping" "x86_64-slc4-gcc34-opt-for-slc4_amd64_gcc34/lib"
"TagMapping" "x86_64-slc4-gcc34-opt-for-slc4_amd64_gcc34/lib"
</rel>
</obj>
N.B. The template above was based on
/r16/atlas/tdaq/tdaq/tdaq-02-00-00/installed/../installed/share/data/daq/sw/external.data.xml:<obj class="SW_ExternalPackage" id="MYSQL">