[Dachs-support] TAP only catalogue

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Tue Apr 19 10:26:12 CEST 2022


Yannick,

On Fri, Apr 15, 2022 at 12:40:00PM +0200, Yannick Roehlly wrote:
> 
> In fact, I changed my mind and I'm publishing a cone search as it
> may be useful for scientists to query just a location in the
> simulation. I just added a note in the service description stating
> that the positions are not actual ones.

Yes, that is certainly a nice service -- you never know in what
context such a cone search crops up.  I'd actually advise to have
something like "simulated position" or so in the descriptions of the
ra/dec columns; that could help those unsuspecting souls that didn't
bother to read the table description in time.

> I used to publish the form renderers as `ivo_managed` in addition to 
> `local` as it's in the SCS RD skeleton.  Is this useful to do that?

Yes.  Interfaces like WIRR
<http://dc.zah.uni-heidelberg.de/wirr/q/ui/fixed> will turn these
into "Web" links intended for "casual" (i.e., browser) users, and
this kind of thing becomes particularly useful in a cross-domain
context, where non-astronomers discover our resources; our metadata
already is in b2find, http://b2find.eudat.eu/.  I'm a bit surprised
they don't show these browser interfaces yet (at least not on
http://b2find.eudat.eu/dataset/6de8a952-06b2-5069-8fc7-fcca20adb24a)
-- I *think* I'm giving them to them.  I'll investigate.

Granted, I'm not sure what a biologist would do with your simulated
data, but who knows?

> When a column is a Boolean and is used in the web form it appears
> as an unchecked box (i.e. meaning false). If nothing is changed in
> the form, the result page states that the column is used as a
> parameter (e.g. `qFlag: False`) but the condition is not taken into
> account in the results. If I check the radio button, the parameter
> is changed to `qFlag: True` and the results are correct.

Interesting point.  Technically, that's because a checkbox in HTML
forms produces a parameter when checked and nothing at all (a NULL,
if you will) if not.  DaCHS' basic handling of parameters is that
they don't produce constraints if not given (and overriding *that*
specific behaviour is really hard).

> I think I raise the issue some times ago because it was impossible to use a 
> Boolean column in the search form as DaCHS was giving the proper answer with 
> the false value and it was impossible to query for "any value". Maybe you 
> changed something but now it's impossible to query on the false value.

No, it's been like this forever.

> Would it be difficult to render a Boolean column with radio buttons or a 
> select with "true / false / any"? Note that it is not a big issue.

Not with a checkbox -- you can either interpret NULL as "nothing" (as
it's done now) or as "false" (in which case you don't get an "any"
option).

But I give you the current behaviour doesn't feel right; I suppose I
never noticed it because I'm avoiding booleans where I can anyway
(and that's because ADQL can't do them and adding them to ADQL is a
huge pain).

To have a three-state boolean on a column, you can do something like
this:

    <condDesc>
      <inputKey original="l1sat" type="text" required="False"
          multiplicity="single">
        <values default="None">
          <option>Yes</option>
          <option>No</option>
        </values>
      </inputKey>
      <phraseMaker>
        <code>
          colName = inputKeys[0].name
          val = inPars[colName]
          if val=="No":
            yield f"NOT {colName}"
          elif val=="Yes":
            yield f"{colName}"
          # Fall though: Ignore the input (that includes the ANY option)
        </code>
      </phraseMaker>
    </condDesc>

(in the wild in
http://svn.ari.uni-heidelberg.de/svn/gavo/hdinputs/liverpool/res/rawframes.rd
-- make sure you get the http version --, rendered at
http://dc.g-vo.org/liverpool/res/rawframes/q/form).  Note that
colName here is controlled by us, so this particular use of f"..." in
query generation does not create a SQL injection bug.

I'm still not 100% happy with this, as the "ANY" option should be
selected by default (it needs to be there so you can unselect a Yes
or No); and I'm not decided whether something like that should become
the default for boolean columns or if this is material for howDoI.

Opinions (from anyone on this list) are welcome.

         -- Markus


More information about the Dachs-support mailing list