[Dachs-support] TAP only catalogue

Yannick Roehlly yannick.roehlly at lam.fr
Tue Apr 19 14:00:42 CEST 2022


Hi Markus,

Le mardi 19 avril 2022, 10:26:12 CEST Markus Demleitner a écrit :
> 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.

Good advice indeed.

> 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).

What do you mean by “ADQL can't do them”? Do you mean as a proper Boolean?

In ADQL, I can't do `select * from schema.catalogue where flag` (which is 
valid in SQL if flag is a Boolean) but I can do `select * from 
schema.catalogue where flag = 'True'` (which works in SQL too, at least with 
PostgreSQL).

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

Well, your code snippets does not work as this because of the `<values 
default="None">`; DaCHS complains that:

Exception payload: Literal 'None' passed as a value to validateOptions

If I remove `default="None"` it seems to work as expected. `default="ANY"` 
also works except that the ANY choice is not displayed any more so you can't 
change your mind once you've selected an option. ;-)

> I'm not decided whether something like that should become
> the default for boolean columns or if this is material for howDoI.

I think it's worth an entry in the howDoI.

Maybe a better default behaviour who be to produce a select box with an empty 
entry selected by default for ANY, then one entry for True, and for False.

Thanks again.

Best,

Yannick

-- 
After the last of 16 mounting screws has been removed from an access
cover, it will be discovered that the wrong access cover has been removed.





More information about the Dachs-support mailing list