The data tables facility allow you to define a structured data base table via an XML definition in a RAMADDA plugin. There is also an upload API available.

The RAMADDA database facility looks for any plugin file that ends with "db.xml", e.g., testdb.xml in the plugins directory. There are lots of examples on Github

Here is an example DB xml file that defines an "example_instrument" database.

<tables>
  <table   id="example_instrument"  name="Example Instrument" cansearch="true"  canlist="true">
    <column  name="temp"  type="double"  label="Temperature"   />
    <column  name="rh"  type="double"  label="Relative Humidity"   />
  </table>
</tables>

Each database table is defined with a table tag. There can be any number of table tags contained by the outer tables tag. You need to specify a unique id and a name. Contained in the table tag are a set of column definitions. Each column has a name which ends up being the database column name so this should be legal sql. The column definition also contains a label and a number of flags, e.g. cansearch, canlist, that determine whether the column is shown in the list and in the search form.

The column type attribute can be one of:

string
enumeration
enumerationplus
date
datetime
double
int
latlon
latlonbbox
clob
email

If the column is an enumeration then you also have to specify a column separated list of values. See the prioriity example below. The enumerationplus type allows the user to enter their own value and/or use values that have already been created. If its a string or a clob then you also need to specify a size (byte size)

Here is another example, a tasks data table -

<table id="tasks" name="Tasks" icon="/db/tasks.gif">
  <column name="title" type="string" label="Title" cansearch="true"   canlist="true" required="true"/>
  <column name="priority" type="enumeration" label="Priority" values="High,Medium,Low" cansearch="true"   canlist="true"/>
  <column name="status" type="enumeration" label="Status" values="Not Started,In Progress,Completed,Deferred,Waiting" cansearch="true"   canlist="true">
    <property name="iscategory" value="true"/>
  </column>
  <column name="complete" type="percentage" label="% Complete" cansearch="true"   canlist="true"/>
  <column name="assignedto" type="enumerationplus" values="" label="Assigned To" cansearch="true"   canlist="true">
    <property name="iscategory" value="true"/>
  </column>
  <column name="description" type="string" label="Description"  canlist="false" rows="5" columns="40" size="10000" />
  <column name="startdate" type="date" label="Start Date" cansearch="true"   canlist="true"/>
  <column name="enddate" type="date" label="End Date" cansearch="true"   canlist="true"/>
</table>

Column tags can also contain property tags If a column tag has a property tag iscategory then the categorical views are shown, e.g.:

<column>
  <property name="iscategory" value="true"/>
</column>

If a column has a "label=true" property, e.g.:

  <property name="label" value="true"/>

then that column value is used as the label for the entry.

You can define additional display templates. These show up in the "View As" menu in the search form. Templates are specified within the table tag with a template tag. There can be any number of templates. A template is defined with an id, name and (optional) mimetype. You can define optional prefix and suffix. The main part of the template is define with the contents tag. This holds macros with the names of the table columns.

<tables>
  <table  id="airplane_crashes"  name="Airplane Crashes"  icon="/db/database.png" >
    ...
    <template id="t1" name="Template 1" mimetype="text">
      <contents>
	<![CDATA[
<h2>Crash</h2>
Date: ${date}<br>
Location: ${location}<br>
Operator: ${operator}
]]>
      </contents>
      <prefix>
	<![CDATA[<h1>Crashes</h1>]]>
      </prefix>
      <suffix>
	<![CDATA[End]]>
      </suffix>
    </template>
  </table>
</tables>

Each DB entry can have it's own properties like a regular entry type. This is accomplished by adding a basetype section to the table definition. For example, below there is an example instrument database defintion. The basetype section defines properties for the instrument entry, e.g., that the spatial area is shown in the form, its icon and a site_id property.

<table   id="example_instrument"  name="Example Instrument" cansearch="true"  canlist="true">
  <!--
      To add properties to the example_instrument entry add a basetype node that contains
      the type columns. you can also add properties, icons and default wiki text
    -->
  <basetype>
    <property name="form.area.show" value="true"/>
    <property name="icon" value="/icons/someicon.png"/>
    <column  name="site_id"  type="string"  label="Site ID"   />
    <wiki>
      <![CDATA[
+section title={<noop>{name}}
{<noop>{display_linechart }} 
-section
	]]>
    </wiki>
  </basetype>
  <column  name="temp"  type="double"  label="Temperature"   />
  <column  name="rh"  type="double"  label="Relative Humidity"   />
</table>

You can define sub-querys that allow you to specify a "not in" logic with the macro specification.

<table ... >
<macro name="Label to show in form" column="the not in column name"
       columns="comma separated list of query columns. can be column1:label1,column2,column3:label3">
<description><![CDATA[html to show in form]></description>
</macro>
...
</table>

For example, in a campaign contribution database the below macro allows the user to search where the full_name does not show up in any query on election_year, candidate or committee

<table  id="campaign_contributions"  name="Campaign Contributions" >
<macro name="But not donations that..." column="full_name"
       columns="election_year:Donation in year,candidate:Donation to,committee:Donation to committee">
<description><![CDATA[                                                                                                                             
<center><div class="ramadda-note">Don't select donations that match this criteria</div></center>]]></description>
</macro>
...
</table>