TAP 1.1, MAXREC and TOP

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Mon Aug 31 11:15:32 CEST 2015


Dear DAL,

I believe we should use the opportunity of TAP 1.1. to clarify the
interaction of TAP's MAXREC and ADQL's TOP.

True, TAP is more general than ADQL, but the large majority of TAP
queries are ADQL, and differing behaviours between various servers
are an annoyance.

Essentially, the question is:  What's to happen when MAXREC=200 is
specified in a query parameter, and there's a TOP 4000 clause in
QUERY?

There certainly are good arguments to say "use the minimum of both
numbers", but I'd argue for "use what's in the query", as that
probably is most directly what the user wrote. You see, at least in
TOPCAT, and I suspect in other clients, too, MAXREC is a bit out of
the focus of the user interface but preset.  It's unlikely that users
having wrote a TOP clause differing from MAXREC actually set
MAXREC conciously.

A slight drawback might be that, to figure out the metadata-only case
of MAXREC=0 (or SELECT TOP 0), a service needs to parse the query.
It would have to do that anyway, though, to produce the metadata
requested, so I don't think that's a major problem.

If we can reach an agreement on this, I'd say we should change sect
2.7.5 of the current 1.1 draft.  Where there's now

  The MAXREC parameter and its effect on the query result is fully
  described in [std:DALI]. If the result set is truncated in this
  fashion, it must include an overflow indicator as specified in
  section XREF.

I propose we should write

  TAP supports the MAXREC parameter as specified in [std:DALI],
  version 1.0, where what is limited is the number of database rows
  in the first result table; where TAP jobs produce multiple tables,
  the row counts of the other tables are not included.
  
  However, many query languages transported by TAP have
  their own mechanisms for limiting the number of records to be
  returned; for instance, in ADQL there is the <set_limit> production
  ("TOP n").  When a query gives both MAXREC and such a
  language-specific row limit, the language-specific limit overrides
  MAXREC (as it was presumably directly entered by the user).  When a
  query gives no MAXREC but a language-specific set limit, services
  SHOULD (next major version: MUST) behave as if MAXREC were set to
  the language-specific set limit.

  If a result is truncated due to MAXREC (or an equivalent
  mechanism), the query response must include an overflow indicator
  are specifiec in sectin <ref>

What does everyone think?

Cheers,

        Markus



More information about the dal mailing list