TAP 1.1, MAXREC and TOP

[Gregory Mantelet]

     Mark, would it be otherwise possible in TOPCAT (and eventually 
STILTS' TAP client), to automatically update the MAXREC parameter to the 
TOP value if TOP > soft_limit? And in case TOP > hard_limit, set MAXREC 
to hard_limit?

     This would be a convenient solution in advanced TAP client such as 
TOPCAT, because it would be more natural to the users who, most of the 
time, do not know what is MAXREC for in the contrary of TOP.

Cheers,
Grégory


On 02/09/2015 11:58, Mark Taylor wrote:
> On Wed, 2 Sep 2015, Kristin Riebe wrote:
>
>> Dear DAL
>>
>>> And, given that, I'd wish clients would not pass in MAXREC by
>>> default.  Mark... Do you think you could have the Max Row combo in
>>> TOPCAT default to empty?
>> Are you sure this would be wise?
> I *think* it's not only wise, but what topcat actually does.
>
> The Max Rows selector visible in the GUI displays the soft limit
> obtained from the TAPRegExt document at the service's /capabilities
> endpoint, like this:
>
>     Max Rows: 2000 (default)
>
> (see http://www.starlink.ac.uk/topcat/sun253/TapTableLoadDialog_query.html
> for a screenshot).
>
> In this state (flagged to the user by the "(default)" marker)
> the client does not supply the MAXREC parameter to the service
> when it makes TAP queries.
>
> However, if the user interacts with the Max Rows selector GUI
> to set the value to something other than the default (i.e. different
> from the declared MAXREC soft limit), then subsequent TAP queries
> are sent to the service with a MAXREC parameter.
>
> In other words the combo box doesn't default to empty, so users can
> see what they can expect in terms of result truncation,
> but the TAP client behaves as if it did.
>
> Markus, if you think you're seeing different behaviour than that,
> get in touch off-list and I'll check it again.
>
>> I thought MAXREC was set by default so that people do not accidentally
>> download complete large tables, especially since they may need to first
>> try around a bit to get the query right, but may forget to set TOP to
>> limit their results during this try-out phase.
> That is the way it works, and it's a good idea for the reasons that
> you mention, but the MAXREC soft (i.e. default) limit is enforced
> by the service rather than (necessarily) the client.
> The client software only gets to override the soft limit if it
> passes MAXREC explicitly, so if it leaves that parameter out
> then the server-declared soft limit applies.
>
> In general: I think I agree with what appears to be the consensus
> on this thread, which is that MAXREC trumps TOP, and only MAXREC
> results in the QUERY_STATUS OVERFLOW flag.  This is what I expect
> from the existing standard text.  I know that DaCHS does it
> differently, and admittedly I have generally been pleasantly surprised
> by that non-standard behaviour when I've noticed it, since it
> does what I want; however I think it would complicate the
> standard too much to legislate for that behaviour.
> The fact that taplint does not report this behaviour as erroneous
> may be the result of my culpably pro-DaCHS bias.
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/