Difference between revisions of "ConditionsData"

From Mu2eWiki
Jump to navigation Jump to search
Line 52: Line 52:
 
  2, 1.1, BAD <span style="color:red"># malformed comment - will appear in string column</span>
 
  2, 1.1, BAD <span style="color:red"># malformed comment - will appear in string column</span>
 
  3, 1.1, failed check #3  <span style="color:green">OK, legal to use hash in string</span>
 
  3, 1.1, failed check #3  <span style="color:green">OK, legal to use hash in string</span>
<li> commas must be quoted
+
<li> commas must be quoted</li>
 
  TABLE tableName2
 
  TABLE tableName2
 
  1, 1.2, GOOD
 
  1, 1.2, GOOD
 
  2, 1.1, BAD, or not <span style="color:red">will crash on parse</span>
 
  2, 1.1, BAD, or not <span style="color:red">will crash on parse</span>
 
  3, 1.1, "BAD, or not" <span style="color:green">OK</span>
 
  3, 1.1, "BAD, or not" <span style="color:green">OK</span>
<li> double quotes must be quoted, and escaped or doubled. You can always use quotes.</li>
+
<li> double quotes must escaped or doubled. quoting full string </li>
 
  TABLE tableName2
 
  TABLE tableName2
 
  1, 1.2, GOOD <span style="color:green">OK</span>
 
  1, 1.2, GOOD <span style="color:green">OK</span>
  1, 1.2, "GOOD" <span style="color:green">OK, probably good policy</span>
+
  1, 1.2, "GOOD" <span style="color:green">OK</span>
  2, 1.1, Joe says "BAD" <span style="color:red">will crash on parse<span>
+
3, 1.1, really BAD  <span style="color:green">OK, multiple words OK (as long as no commas or quotes)</span>
 +
  2, 1.1, Joe says "BAD" <span style="color:green">OK</span>
 +
2, 1.1, Joe says "BAD, or not" <span style="color:green">OK, comma requires quotes</span>
 
  3, 1.1, "Joe says \"BAD\"" <span style="color:green">OK</span>
 
  3, 1.1, "Joe says \"BAD\"" <span style="color:green">OK</span>
 
  4, 1.1, "Joe says ""BAD""" <span style="color:green">OK</span>
 
  4, 1.1, "Joe says ""BAD""" <span style="color:green">OK</span>
 
  4, 1.1, "Joe says "BAD"" <span style="color:red">will crash on parse<span>
 
  4, 1.1, "Joe says "BAD"" <span style="color:red">will crash on parse<span>
  5, 1.1, "Joe says, ""BAD""" <span style="color:green">OK</span>
+
  5, 1.1, "Joe says, ""BAD""" <span style="color:green">OK, comma requires quotes, embedded quotes must be escaped or doubled</span>
 
</ol>
 
</ol>
  

Revision as of 17:36, 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
  • 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

  1. when adding comments to a dbTool create action, such as creating a new purpose or version
  2. 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:

  1. if more than one word, use double quotes --comment "two words"
  2. when using a double quote in a string (if you even have to...) escape it --comment "two \"words\""

When writing a file that contain calibration data, the following rules apply

  1. 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.
  2. # this is a legal comment TABLE tableName1 1, 1.2 # legal comment 2, 1.1 # illegal comment - will crash on parse 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
  3. commas must be quoted
  4. TABLE tableName2 1, 1.2, GOOD 2, 1.1, BAD, or not will crash on parse 3, 1.1, "BAD, or not" OK
  5. double quotes must escaped or doubled. quoting full string
  6. 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