TAP 1.1: The table_name values must be unique

[Van Klaveren, Brian N.]

Hi All,

It was great seeing everyone this last week. I have a question on TAP 1.1 I forgot to bring up:

For TAP_SCHEMA.Tables, TAP 1.1 says:

The table_name values must be unique. The value of the table_name should be the string that is recommended for use in querying the table; it may or may not be qualified by schema and catalog name(s) depending on the implementation requirements.

I just wanted to say that I think this makes TAP_SCHEMA tables slightly awkward when you deal with multiple catalogs and schemas, and it seems to be mostly in an effort to prevent an additional `schema_name` column in TAP_SCHEMA.Columns, TAP_SCHEMA.Keys, etc... Relatedly, there's no catalog.

So for a theoretical use case, say I have `oracle.bvan.MyTable` where I created my TAP table, where `oracle.bvan` is really the schema_name (since there's not catalog_name).

But I also want a table `qserv.bvan.MyTable` and a table `oracle_dev.bvan.MyTable`.

This means I have something like the following:

TAP_SCHEMA.Schemas
| schema_name     |
| oracle.bvan     |
| oracle_dev.bvan |
| qserv.bvan      |


TAP_SCHEMA.Tables
| schema_name     | table_name              |
| oracle.bvan     | oracle.bvan.MyTable     |
| oracle_dev.bvan | oracle_dev.bvan.MyTable |
| qserv.bvan      | qserv.bvan.MyTable      |


Which, from a programmatic standpoint, means that an application must never naively qualify a table name as ( schema_name + "." + table_name ) when constructing a query.

I suppose that's not a dealbreaker, but I do think it's awkward, and it deviates from the sql99 approach of using the effective "catalog_name", "schema_name", and "table_name" everywhere:

(Linking to postgres docs for simplicity):
https://www.postgresql.org/docs/9.1/infoschema-tables.html
https://www.postgresql.org/docs/9.1/infoschema-columns.html
https://www.postgresql.org/docs/9.1/infoschema-table-constraints.html

I think I'd personally prefer there to be IDs and there to be joins on IDs rather than names in a future TAP 2.0 so joins are easier, but maybe at least adding schema_name columns to TAP_SCHEMA.Columns and TAP_SCHEMA.Keys, etc... in the future would be a better approach, and just force a unique constraint on TAP_SCHEMA.Tables for schema_name and table_name, though I would like to see a CATALOG_NAME in there too.

Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20181116/219a99ef/attachment.html>