TAP information schema

[Doug Tody]

Part of the problem of defining TAP is working out how TAP and ADQL
integrate, such as how to reference a table stored in a local VOSpace
(managed by the TAP service) from ADQL.  Many of the folks responsible
for the ADQL spec are also involved in defining TAP for this reason.
- Doug


On Fri, 12 Oct 2007, 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.
> 
> 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.
> > >
> > >
>