table_name syntax

[Dave Morris]

Hi Mark, Laurent,

On 2015-04-29 10:18, Mark Taylor wrote:

> Most clients do not need to do that kind of parsing.  If all you want
> to do is display table metadata or assemble ADQL text (these are the
> things topcat needs to do, and I guess TapHandle too), or ensure
> uniqueness of the table+column content as mentioned by Marco,
> you can just use the table_name value.  This is a guaranteed unique
> identifier for the table; it may or may not include a schema
> (or catalog.schema) prefix according to whether it's required for
> uniqueness, which is something the service knows and the client
> doesn't need to worry about.
> 

Yep, agreed.

This is established functionality, so I'm not suggesting we change this.

I agree with Laurent, that from the perspective of someone who would 
prefer to have the original names, changing the existing table_name 
column would be a good thing.

However, I can appreciate that this is established functionality, it 
works and is in use by exiting services and clients, so changing it now 
would *not* be a good thing.

So - the existing TAP-1.0 functionality stays in place.

No need to lookup the service capability version, no need to check for 
new columns.

The existing functionality stays.

However ..

> Admittedly, if you need to recover the unqualified and unquoted
> table name for some reason (I get the impression this is one of
> Dave's requirements, though I may be wrong) it's a bit more fiddly
> under the current scheme, but it's not impossible, and I would
> say that's a niche requirement.

Yes, for our use case we need to extract the original, unquoted, 
catalog, schema, table and columns names as separate items.

You are right, it is not impossible to parse the concatenated string.

It will however, become that bit more tricky once we start to have 
nested double quotes and full stops inside a variable number of double 
quote delimited identifiers which are themselves separated by full 
stops.

If it is at all possible I'd prefer to avoid the process of encoding the 
separate names into a concatenated string on the server, only to have to 
decode and parse the string to produce the separate unquoted names again 
on the client.

The server must have the original unquoted names in order to be able to 
create the concatenated string, the request was to make these available 
to the client as two additional columns in the TAP_SCHEMA table.

The cost would be adding two rows to the table description in the 
specification, and two cells per row in TAP_SCHEMA.tables on each 
server, populated with data we know the server must already have.

No cost at all to existing clients that use the concatenated table_name, 
the existing functionality would stay the same and you wouldn't even 
notice the extra columns were there.

You may be right, this may be a niche requirement, but even so, given 
the cost if fairly low - it doesn't seem that big an ask.

It also means that searching for "table name starts with" becomes much 
much easier.


Dave

--------
Dave Morris
Software Developer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------