TAP information schema

[Tony Linde]

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.

T.

> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Doug
> Tody
> Sent: 12 October 2007 03:46
> To: Patrick Dowler
> Cc: dal at ivoa.net
> Subject: Re: TAP information schema
> 
> Hi Pat -
> 
> This is a problem.  TAP should try to solve the portability problems,
> not push this off on applications; application writers will not have
> time to figure all this out.
> 
> If we can't uniformly have both catalog and schema, then we should
> consider a simpler TAP schema where either back-end can be used (as is
> the case in actual DBMSes).  Maybe just "database" and "table", since
> the term "database" is already quite fuzzy even for SQL, or "schema"
> and "table", which would be much the same thing (the service would
> map "database" to either "catalog" or "schema", which ever is more
> appropriate for the back end).  I don't think we should make clients
> try to figure all this out, but I do think that having one level above
> a table is an important generalization for a fully functional TAP.
> 
> 	- Doug
> 
> 
> 
> On Thu, 11 Oct 2007, Patrick Dowler wrote:
> 
> > On 2007-10-11 16:05, Doug Tody wrote:
> > >> Pat wrote:
> > > > For the VOSpace example, if I was implementing that I would most
> > > > likely make vospace a database (for storage allocation purposes),
> > > > require authentication, and give each user implicit schema
> > > > creation privaledge. Then the uploaded VOtable would be known as
> > > > vospace.$user.$tableName and I would have to do minimal work to
> make
> > > > that happen and protect one user's tables from another.
> > >
> > > So what do you do with MySQL (and probably others) where there is
> > > only one catalog?  As we would like to be able to use ADQL to
> access
> > > both vospace tables and data tables in the same query, the only
> option
> > > (other than brute force copying tables) is to implement the vospace
> with
> > > a schema ("database" in MySQL).
> >
> > Well, that is the issue - some people use one catalog and multiple
> schemata
> > and others use multiple catalog and default or implicit (user)
> schemata. We
> > have to accomodate both because both are in use and required in one
> system or
> > another. What I meant was "if  I was implementing VOSpace on top of a
> db that
> > supported multiple of each" (eg DB2 and sybase here). If it is MySQL
> > underneath then the implementor has no choice but to use schemata to
> separate
> > things (either a vospace schema and manually separate tables, or a
> bunch of
> > schemata nominally managed by one VOSpace service. Either is doable.
> I just
> > don't think we can have the TAP metadata dictate which one someone
> choses, so
> > we have to ultimately (maybe not now) expose catalog, schema, and
> table
> > concepts.
> >
> > Anyway, I don't think we disagree. If this was the future ultra magic
> version
> > of VOQL with XQueryMagic and ZOntologyMapper then we could hide
> stuff, but
> > ADQL is mostly SQL and that means we can't hide stuff without being
> bitten
> > later on. Anyone who wants to hide these details can do so by telling
> the
> > user one thing (eg giving them unique table names) and re-writing the
> query
> > to something else, but many arguments have been made that one should
> not have
> > to do this and should in theory be able to more or less pass the
> query
> > through with minor syntactic massaging.
> >
> >