VODataService

[Gerard]

Hi Pat

Why did you not send this to TAP, seems relevant for that as well.

> > It seems to me there might be another possibility to solve 
> your case, 
> > implement a toURL(..) UDF on your database.
> > Users could now use the toURL(pats_uri) in the where 
> clause, though it 
> > would be very inefficient. But it would be clear to them 
> from the fact 
> > that a UDF is needed.
> >
> > To me the big advantage is that it makes explicit to the 
> user what is 
> > happening, which I think is ALWAYS good. It seems to solve 
> the issues 
> > with
> > 1,2,3 and you do not need extra concepts such as 
> select-only columns.
> > Of course I assume it is possible for you to implement a 
> UDF with this 
> > functionality.
> 
> I agree that with ADQL it is important that things be 
> explicit and I am not 100% happy about any of the ideas. 
> However, the assumption that one can implement a UDF is 
> problematic at best. The problem is that when one uses URIs a 
> common practice (and one we have made good use of recently) 
> is that different subsystems provide code or services to do 
> that conversion and they register their scheme and 
> code/service. This is all implementation detail but the point 
> is that it may not be technically feasible to actually run 
> that conversion inside the DB in a UDF. Secondarily, I think 
> any solution that requires a UDF is not implementable by some 
> people, for example when there is an existing DB and TAP 
> access is to be provided but the TAP implementors cannot 
> modify the DB in any way (e.g. they have to do everything in 
> the service code). 
> 
So one question could be whether it is implementable in the actual case at
hand.
Would it be implementable by you using a UDF or an even simpler method?
What other realistic cases are there and will this or an alternative
solution work for them?
What decides when there are enough to warrant introducing new features to a
standard.


> > For now I am against your solution 4.
> > Does the select-only concept have any precedent elsewhere, 
> do you have 
> > references to this? It will require pretty advanced support in ADQL 
> > parsers, though it is not an ADQL concept (ADQL being non-semantic).
> > As far as I know, but I may be mistaken it goes beyond standard RDB 
> > concepts.
> 
> Yes, it is non-standard RDBMS and SQL. It has precedent in 
> various DAL services where the output can (does) contain 
> things that the caller cannot constrain in the request. 
> Specifically, the AccessRef in DAL services is a URL to the 
> data but you cannot constraint it and I very much doubt that 
> anyone actually stores the full URL in the database. And 
> generally it does not make much sense to constrain such a 
> column, but in TAP and ADQL users can do that if the column 
> is visible.  
> 
I was indeed looking for precedents in other RDBMS/SQL solution, not custom
IVOA services.
What it seems you are proposing to do here is to create a particular
semantics for ADQL queries that deviates from standard practice in SQL-based
systems. I don't know if there is actual a (formal) semantics associated to
SQL92 (maybe using a translation to relational algebra?), so I assume that
standard practice in relational databases is that semantics.

I know the ADQL effort very much tried to avoid assigning any semantic
meaning to the grammar, but it seems the burden is now shifting to the
VODataService/TAP specification. Something I believe is also the case in the
discussion on data types (which I think is not yet finished).


> > And it seems not to be necessary.
> 
> Ah, but only if one accepts that implementing UDFs in the DB 
> is necessary, and I think a lot of implementors will be 
> unwilling or unable to do that, for a variety of technical reasons.
> 
I don't think using a UDF is always necessary to create derived columns that
can be used in where clauses and therefore do not require the select-only
tag. I proposed UDFs as a solution in this particular case.
It may in many cases be possible to create a derived column purely in SQL,
as example it is easy to create a POS (==RA,DEC)derived column from an RA
and a DEC column without requiring a UDF.
There may ofccourse well be other cases.

Supposing select-only is accepted. What do you see as the consequences?
I suppose a select-only column transmits its select-only-ness to any
expression it is part of.
For example if it is the result in a sub-query, the wrapping query should
not be allowed to use the result column, possibly changed, in a where clause
eitehr.
Would you be allowed to ask
  select distinct URL ...  ?


(of course I am just conservative, don't like change to things I thought I
was familiar with)

Cheers

GErard