ConditionsData: Difference between revisions
Line 36: | Line 36: | ||
<li> if more than one word, use double quotes</li> | <li> if more than one word, use double quotes</li> | ||
--comment "two words" | --comment "two words" | ||
<li> when using a double quote in a string | <li> when using a double quote in a string, escape it</li> | ||
--comment "two \"words\"" | --comment "two \"words\"" | ||
</ol> | </ol> |
Revision as of 17:48, 3 August 2018
In Mu2e it will eventually be necessary to maintain a database of "calibration constants". This will include information like the measuured corrections to the nominal geometry, the gas gain in straws, the time-space relationship for the straws, the gain of the photosensors, the calibration curve for ADC's and so on. This sort of data was traditionally referred to as "calibration constants" or, simply, as "constants".
Many of the calibration constants, however, are actually time dependent, which leads to the tired joke that "constants aren't". In the interests of ridding the field of bad jokes, modern usage is that this sort of data is known as "conditions data".
- Art interface:
- art talk on a db interface.
- csv_qe_api query_engine wrapper and generic table (`upd list -aK+ csv_qe_api`)
- ConDB - urls access to REST server
- ConDB Web Interface urls that return csv, assumes time IOV
- query_engine wiki - a generic query db url/REST interface
- Web Data Access (wda) manual (ups product) c function wrapper, takes urls, runs curl, returns pointer to memory, has utilities for converting csv to values.
- nu products
- nutools - contains nova generic table
- nucond -
- MINOS DB manual
- UconDB unstructured DB
Notes
- 5/9/18 created dev conditions
psql -h ifdb04 -p 5444 mu2e_conditions_dev
- query engine
non-cached: http://dbdata0vm.fnal.gov:9090/QE/mu2e/dev/app/SQ/query?t=test cached: http://dbdata0vm.fnal.gov:9091/QE/mu2e/dev/app/SQ/query?t=test
- setup postgresql v9_3_9
strings
Arbitrary string input occurs at two places
- when adding comments to a dbTool create action, such as creating a new purpose or version
- when uploading a calibration table that has a string column
In general, there are three special characters to watch our for: double quotes, used for quoting ("), comma, used for column separation (,), and hash, used for comments (#).
When inputing a string to dbTool to include a comment, there are only two rules:
- if more than one word, use double quotes --comment "two words"
- when using a double quote in a string, escape it --comment "two \"words\""
When writing a file that contain calibration data, the following rules apply
- comments may be included by writing the hash (#) as the first character of a line. Comments are not allowed embedded in lines with data. The hash may be used in a string column. # this is a legal comment TABLE tableName1 1, 1.2 # legal comment # legal comment - first non-whitespace char is the hash 2, 1.1 # illegal comment - will crash on parse (part of number column) TABLE tableName2 1, 1.2, GOOD 2, 1.1, BAD # malformed comment - will appear in string column 3, 1.1, failed check #3 OK, legal to use hash in string
- commas must be quoted TABLE tableName2 1, 1.2, GOOD 2, 1.1, BAD, or not will crash on parse 3, 1.1, "BAD, or not" OK
- embedded double quotes must escaped or doubled TABLE tableName2 1, 1.2, GOOD OK 1, 1.2, "GOOD" OK 3, 1.1, really BAD OK, multiple words OK (as long as no commas or quotes) 2, 1.1, Joe says "BAD" OK 2, 1.1, Joe says "BAD, or not" OK, comma requires quotes 3, 1.1, "Joe says \"BAD\"" OK 4, 1.1, "Joe says ""BAD""" OK 4, 1.1, "Joe says "BAD"" will crash on parse 5, 1.1, "Joe says, ""BAD""" OK, comma requires quotes, embedded quotes must be escaped or doubled