Difference between revisions of "ConditionsData"

From Mu2eWiki
Jump to navigation Jump to search
Line 42: Line 42:
 
When writing a file that contain calibration data, the following rules apply
 
When writing a file that contain calibration data, the following rules apply
 
<ol>
 
<ol>
<li> 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.
+
<li> 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.</li>
<pre>
+
# this is a legal comment
# this is a legal comment
+
TABLE tableName1
TABLE tableName
+
1, 1.2
1 , 1.2
+
# legal comment
# legal comment
+
2, 1.1 <span style="color:red"># illegal comment - will crash on parse</span>
2,  1.1 <div style="color:red">illegal comment</div>
+
TABLE tableName2
</pre>
+
1, 1.2, GOOD
<li>
+
  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>
 +
<li> commas must be quoted
 +
TABLE tableName2
 +
1, 1.2, GOOD
 +
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>
 +
<li> double quotes must be quoted, and escaped or doubled.  You can always use quotes.
 +
TABLE tableName2
 +
1, 1.2, GOOD <span style="color:green">OK</span>
 +
1, 1.2, "GOOD" <span style="color:green">OK, probably good policy</span>
 +
2, 1.1, Joe says "BAD" <span style="color:red">will crash on parse<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:red">will crash on parse<span>
 +
5, 1.1, "Joe says, ""BAD""" <span style="color:green">OK</span>
 
</ol>
 
</ol>
  

Revision as of 17:24, 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 TABLE tableName2 1, 1.2, GOOD 2, 1.1, BAD, or not will crash on parse 3, 1.1, "BAD, or not" OK
  4. double quotes must be quoted, and escaped or doubled. You can always use quotes. TABLE tableName2 1, 1.2, GOOD OK 1, 1.2, "GOOD" OK, probably good policy 2, 1.1, Joe says "BAD" will crash on parse 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