Asynchronous querying and tabular data
dtody at nrao.edu
Tue May 1 14:05:22 PDT 2007
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'
> a certain pattern of bytes that happens to be a VOTable, we should get back
> EXACTLY the same bytes when we 'get' it.
> -----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
More information about the voql-teg