The dataset configuration file for a dataset that requires database access must include information that describes the location and nature of the data to the database service. The database service will use this information to access the data and properly convert the data into an intermediate NetCDF file.
The dataset will typically require a new user interface behavior -- the combination of Views/Products/Options presented by the LAS user interface (UI). Both the UI and database access information are specified as a set of properties within the dataset <properties> ... </properties> tags.
The <properties> section of the insitu_demo_1.xml file distributed with LAS is given below:
<db_title>LAS in-situ demo</db_title>
<time_units>hours since 1970-01-01 00:00:00</time_units>
The <ui> properties are described in the section on Configuring the UI for scattered data.
The <database_access> properties are described below:
- one of mysql | ???
- the name of the database to be used when configuring the database (see Configuring the LAS database service)
- title to be used with this dataset (the title will appear on ???)
- domain name of the machine hosting the database server
- name of the table in which the data is stored
- name of the database variable containing longitude values
- range of longitude values stored in the database (typically 0:360 or -180:180)
- name of the database variable containing latitude values
- (optional) name of the database variable containing depth values
- (optional) units associated with the depth variable (e.g. meters)
- name of the database variable containing time values
- units associated with the time variable (e.g. hours since 1970-01-01 00:00:00)
- data type of the time variable stored in the database (use double for all numeric times)
Currently, time_type must be one of double | int | string. The behavior of the database service is to assume that time variables with a type of double have appropriate units and can be written directly into the intermediate NetCDF file. Whenever the database service encounters a time of type int or string it assumes that the time variable has an ASCII representation that must be converted into a floating point value. The conversion is performed by the the org.joda.time library. (If the time variable in your database is stored as type floatyou must still specify double in the <database_access>properties. This will be corrected in a future release of LAS.)
- coaches org.joda.time library on how to interpret ASCII representation sof time (joda time format patterns)
- (optional) name of the database variable containing the profile ID
A profile ID variable can be used to associate multiple records in a database with a single atmospheric or oceanographic profile. If specified, the variable identified by profID will be written to the intermediate NetCDF file as PROF_ID. As released, LAS supports several Ferret based products that rely on the presence of the PROF_ID variable in the intermediate NetCDF file.
- (optional) name of the database variable containing the cruise ID
The comments for profID apply for cruiseID as well.
- missing_value flag to be used in the intermediate NetCDF file
There is currently no way to identify missing value flags that are stored in the database.
- timeout (not yet implemented)
- database timeout
- N.B. In previous versions of LAS, you were required to put the database login and password information in your data set configuration. As of LAS 7.x this is no longer required or recommended. This information is now stored in the database backend configuration file. These properties are ignored by LAS.
- login name with SELECT permission on the required data tables
- password associated with db_login