TAP information schema

[Tony Linde]

Pat was saying (subject to correction) that the service provider puts a FQTN
in as the table name in the registry entry but it is up to the provider
whether that FQTN is exactly what you might put in SQL to the backend
database or whether parsing the ADQL includes translating the FQTN into what
the SQL expects. If the former case, then the service (IFF the ADQL is
exactly equal to what the dbms is expecting as SQL) can pass the ADQL
straight through.

That the registry interface purports to provide an ADQL means of getting
registry entries is misleading: it isn't really ADQL, just uses the grammar
of the ADQL WHERE clause (and I'm not sure if it still meets the newer ADQL
spec). It would be good to lose that part of the registry interface in the
future or define it separately.

T.

> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of
> Gretchen Greene
> Sent: 12 October 2007 18:28
> To: 'Patrick Dowler'
> Cc: dal at ivoa.net
> Subject: RE: TAP information schema
> 
> Patrick,
> 
> Thanks for pointing out the requirements for fully qualified table
> names,
> it appears to be a case of
> oversimplification is the early presented usage.
> 
> I really am not clear on what your summary means in terms of how a
> client
> will access the tap services.
> I thought ADQL was to provide the query language specification for
> accessing
> tap services,  but maybe I'm
> missing something in your point of accessing them through registry
> protocols.
> 
> A VORegistry persistence of service table names and columns are
> theoretically available via the standard registry interface.  This
> interface
> can be queried as keyword or adql, thus I do not see how we are
> escaping the
> issue of adql not handling
> full db table schema name specifications unless we limit the query
> level.
> 
> -Gretchen
> 
> 
> 
> 
> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Patrick
> Dowler
> Sent: Friday, October 12, 2007 1:03 PM
> To: Undisclosed.Recipients :
> Cc: dal at ivoa.net
> Subject: Re: TAP information schema
> 
> 
> It isn't really all that dire :)
> 
> The crux is that to use TAP the user needs to know the table name
> unambiguously; in the db this is the fully qualified table name (FQTN
> for
> short), which is $catalog.$schema.$table
> 
> For the purposes of TAP 1.0, it would be sufficient to say that the
> VOResource
> metadata about tables an columns (which is what one needs for discovery
> anyway) has to specify unique, unambiguous table names.
> 
> What we should be careful about is to make sure that we do not include
> any
> semantic meaning in such FQTNs - just say they have to be unique within
> the
> service and leave it at that. In MySQL there is one catalog, so FQTNs
> can be
> 
> reduced to $schema.$table in that case. In general one always has a
> default
> catalog they are connected to, so any TAP service which keeps all the
> content
> in one catalog could do the same... others that expose multiple
> catalogs via
> 
> a single TAP (eg upload VOTables to a VOSpace and they are available in
> the
> 
> service) might want to do that or they might want to use a separate
> catalog;
> 
> that is defintely what I would do. Still others might have historically
> used
> 
> the catalog as the namespace (we do that in our sybase servers, eg), so
> there
> we would use FQTNs like $catalog..$table or $catalog.dbo.$table.
> 
> Summary: I think we could get away with just having 1+ opaque unique
> table
> names in the VOResource metadata and TAP implementors can decide if
> they
> want
> to put something arbitrary and map it to their DB or they can just put
> their
> 
> real FQTN in there and not have to process the ADQL at all. We just
> have to
> make sure this thing has no specific meaning (well, people will see and
> parse
> it and make assumptions anyway, that's unavoidable) that ties us down
> later.
> 
> my 2c,
> 
> Pat
> 
> On 2007-10-12 01:08, Tony Linde wrote:
> > I thought TAP was a mechanism for sending ADQL through to registered
> > services. The various posts here sound like trying to solve perceived
> > problems with ADQL and Registry in TAP: that IMHO is the wrong way
> round.
> > TAP spec should simply be used to push ADQL to a service then you get
> the
> > changes you want into ADQL and the Registry and TAP still works. If
> ADQL
> is
> > changed so that it supports qualified table names then, and only
> then,
> > should you update TAP to support the new spec, not try to predict
> what
> ADQL
> > might look like in the future. If OTOH you are saying no-one can
> possibly
> > use ADQL as it stands and there is no point producing TAP based on
> the
> > current ADQL spec then you should get ADQL changed first, but I
> really do
> > not think that is the case.
> 
> --
> 
> Patrick Dowler
> Tel/Tél: (250) 363-6914                  | fax/télécopieur: (250) 363-
> 0045
> Canadian Astronomy Data Centre   | Centre canadien de donnees
> astronomiques
> National Research Council Canada | Conseil national de recherches
> Canada
> Government of Canada                  | Gouvernement du Canada
> 5071 West Saanich Road               | 5071, chemin West Saanich
> Victoria, BC                                  | Victoria (C.-B.)
> 
>