Asynchronous querying and tabular data

[Doug Tody]

Ok.  But if TAP creates the (possibly quite large) table as the result
of an SQL query, there are no bytes-in.  It would make more sense to
merely have the local VOSpace manage the DBMS table on behalf of the TAP.
Then a subsequent query could re-use the DBMS table directly, or the
VOSpace could serialize it on the fly for transfer to a remote client
or another VOSpace.  - Doug


On Tue, 1 May 2007, Alex Szalay wrote:

> My take n this would be that the VOSpace is bytes-in, bytes-out. If we 'put'
> in
> a certain pattern of bytes that happens to be a VOTable, we should get back
> EXACTLY the same bytes when we 'get' it.
>
> --Alex
>
> -----Original Message-----
> From: owner-voql-teg at eso.org [mailto:owner-voql-teg at eso.org] On Behalf Of
> Doug Tody
> Sent: Tuesday, May 01, 2007 4:46 PM
> To: Patrick Dowler
> Cc: voql-teg at ivoa.net
> Subject: Re: Asynchronous querying and tabular data
>
> Of course async and VOSpace go together, but a subtle issue here is what
> exactly it means to store a table in VOSpace.  Is the table stored as a DBMS
> table managed by the VOSpace, or as a file (e.g., a VOTable)?
> Probably the former, with serialization occuring only at access time, e.g.,
> when a remote client retrieves the table.  Hence TAP would compute the
> output table, and somehow hand it off to the local VOSpace, which would
> manage it thereafter.  If the output VOSpace is remote, then is the table
> serialized for transfer, and in so in what format?  Is it ingested and
> stored as a file or as a DBMS table on the remote VOSpace?
>
> If ultimately we want to be able to upload large tables to be used in a
> query, or store output tables as intermediate results, then the VOSpace will
> want to at least be co-located on the same DBMS.  As you suggest, TAP and
> VOSpace could probably be separate services however.
>
> 	- Doug