Defining tables

Defining table products

Here we take a path focusing on the final products, what is delivered by the service interfaces.

Some services deliver pre-defined tables -- or products; the words get mixed, I'll try my best, you have to follow ;). That is the case for SSA, for example. Let us here, then, understand how are those tables defined and see the steps to fill them.

The main piece for defining a table is the mixin component of your table element (remember table. There is an expressive list of pre-defined mixins, for most common tables structure out there; but -- if needed -- you can also customize them for particular needs.

For instance, during the very first steps of Growing-an-RD, till make-it-work/data section, we saw such aspects of the SSA (_hcd mixin_) service. To see the table a service/mixin [*] is to deliver we can do something like that and put empty tables up.

For example, we can try to import the following test tables [†]: (To ease, I have removed all elements not strictly necessary)

<resource schema="test">
        <table id="main" onDisk="True">
          <mixin>//scs#positions</mixin>
        </table>
        <data id="import">
          <make table="main"/>
        </data>
</resource>

or

<resource schema="test">
        <table id="main" onDisk="True">
          <mixin
            fluxCalibration="ABSOLUTE"
            fluxUnit="erg/(s.cm**2)"
            spectralUnit="Hz"
            > //ssap#hcd
          </mixin>
        </table>
        <data id="import">
          <make table="main"/>
        </data>
</resource>

and then -- after doing gavo import test/q.rd from inside your DaCHS' inputs directory -- go to http://localhost/tableinfo/test.main to see what is being setup. Those are (examples of) the minimal tables that would be available to the user through (scs and ssa, resp.) service interfaces.

So, our job here is to visualize and understand this internal structure so that we can properly fulfill their requirements (feed information), and possibly expand when necessary.

[*]	_service_ and _mixin_ are here being used almost indistinctly, once we are talking about the table's structure to fit a service expected output.

[†]	notice that both examples are to setup a main table for test schema, both can not run simultaneously; try one, and then the other.

SSA

The (pre-defined) mixins for ssa are: //ssap#hcd and //ssap#mixc. They differentiate in what regards a set of constant parameters [‡]; hcd has a larger set of (pre-defined) parameters, as it is meant to declare (spectral) data produced by the same instrument/pipeline (i.e, homogeneous dataset); while mixc is meant for heterogenous datasets, where some "parameters" -- like fluxCalibration, for example -- would possibly change across table's entries, and so they must be define for each row.

The parameters available for each mixin can be seeing at //ssap#hcd and //ssap#mixc DaCHS' documentation.

The way to fill an ssa table is through the use of the (pre-defined) procedures: //ssap#setMeta and //ssap#setMixcMeta. The latter -- setMixcMeta -- is used after the primer -- setMeta -- when the mixc mixin is called. Such procedures are called from rowmaker element procDef argument.

Also, to properly setup the necessary (ssa) service, we have to call the //products#define at (grammar's) rowfilter.

Summary

So, to have the SSA table, minimally working, be sure to have (one of):

  <table ...>
    <mixin ...> //ssap#hcd </mixin>
  </table>
  <data ...>
    <rowfilter procDef='//products#define'>
      ...
    </rowfilter>
  </data>
  <make ...>
    <rowmaker ...>
      <apply procDef='//ssap#setMeta'>
        ...
      </apply>
    </rowmaker>
  </make>

or

  <table ...>
    <mixin ...> //ssap#mixc </mixin>
  </table>
  <data ...>
    <rowfilter procDef='//products#define'>
      ...
    </rowfilter>
  </data>
  <make ...>
    <rowmaker ...>
      <apply procDef='//ssap#setMeta'>
        ...
      </apply>
      <apply procDef='//ssap#setMixcMeta'>
        ...
      </apply>
    </rowmaker>
  </make>

[‡]	Parameters can be seeing as values to be replicated to every entry of the table, defining columns of constant values.

Output

TODO: outputField

Mind

• Products (define)
• DataLink