TAP MAXREC interpretation

Gregory MANTELET gregory.mantelet at astro.unistra.fr
Thu Dec 14 14:51:17 CET 2023


Dear Pierre,

I agree this is not convenient for a client or user. What my TAP library 
does on server-side is to set the MAXREC to min(max_output_limit, 
user_MAXREC) and if the result really exceeds this limit an overflow 
flag will be raised. As far as I know, this is the behavior described by 
TAP-1.x and DALI.

In order to avoid the kind of problem you describe on client-side, I 
would recommend to read the max/hard output limit (xpath: 
/vosi:capabilities/capability/outputLimit/hard) provided in the 
/capabilities endpoint of the TAP service 
(https://mast.stsci.edu/vo-tap/api/v0.1/hsc/capabilities for the TAP 
service you tried) and to perform yourself the correction of the MAXREC, 
if needed. It is indeed not ideal but, if this piece of information is 
provided in this endpoint, this trick may prevent this error in the future.

Cheers,
Grégory


On 14/12/2023 14:37, Pierre Fernique wrote:
>
>
> Dear TAP experts,
>
> While testing the various TAP services accessible via Aladin Desktop, 
> I discovered an interpretation of the MAXREC parameter that I hadn't 
> anticipated, and I'm wondering about its validity.
>
> For example, if I query MAST TAP HSC, with a MAXREC of 2M, I don't get 
> the table I want, but an error as shown below.
>
> https://mast.stsci.edu/vo-tap/api/v0.1/hsc/sync?REQUEST=doQuery&LANG=ADQL&*MAXREC=20000000*&QUERY=SELECT+table_name+FROM+TAP_SCHEMA.tables
>
> <VOTABLE version="1.4" 
> xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.3 
> http://www.ivoa.net/xml/VOTable/v1.3">
>    <DESCRIPTION>MAST VO TAP Service</DESCRIPTION>
>    <RESOURCE type="results">
>       <INFO name="QUERY_STATUS" value="ERROR">
> *Error in query maxrec: ensure this value is less than or equal to 100000*
>      </INFO>
>    </RESOURCE>
> </VOTABLE>
>
> But I would have expected to receive the result correctly, possibly 
> truncated (OVERFLOW mention) at the internal limit of the service 
> (100000).
>
> In fact, such an approach makes it difficult for the client to use 
> MAXREC, except by trial and error appoach. Either it's too high and I 
> get an error, or it's too low (but by how much) and I may not get the 
> full result when I could have. And finally, if I don't specify a 
> MAXREC, the server will apply the default value, even though I could 
> have asked for more.
>
> Any advice on how to deal with this problem?
>
> Thanks
> Pierre Fernique
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20231214/4a70f0fe/attachment.htm>


More information about the dal mailing list