TAP information schema

[Doug Tody]

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. 
> 
>