MAXREC in Datalink

[Markus Demleitner]

Dear DAL,

After reading

  If the client submits more ID values than a service is prepared to
  process, the service should process ID values up to the limit and
  must include an overflow indicator in the output as described in
  DALI. The service must not truncate the output within the set of
  rows (links) for a single ID value if the request exceeds such an
  input limit.

in the current master branch of the datalink 1.1 draft, I somewhat
hotheadedly assumed that Datalink was supposed to support MAXREC and
put such code into DaCHS.  Only when I noticed that my current
implementation didn't do any QUERY_STATUS at all, I started to
wonder, and, sure enough, Datalink 1.0 didn't say anything about
QUERY_STATUS, and Datalink 1.1 doesn't say anything about MAXREC.

Now, I'd say there's not terribly much merit in supporting MAXREC on
datalink services (DaCHS will do it anyway, not that I've already put
it in) -- I can't see much of a scenario there, at least if we agree
that a Datalink services shouldn't return more than a couple of 100
links per ID, and I think we should do that because for UI
considerations.

But if we say that we should have a 

  <INFO name="QUERY_STATUS" value="OVERFLOW"/> 

(which the above passage does), I'd say we should also say clients
must produce

  <INFO name="QUERY_STATUS" value="OK"/> 

as per DALI 1.2.  Of course, that would make datalink 1.0 services
nonvalid for 1.1, which I think we're not allowed to declare.

So, perhaps we should say they "should" produce the query status, and
that it defaults to QUERY_STATUS=OK?  Perhaps that defaulting would
even be a good addition to DALI?

But when we do that, the next question is if there's any way a
datalink QUERY_STATUS could ever be ERROR, given that at least many
errors are reported in-table.  Is there a point for really serious
errors ("No database connectivity") being reported in this way
(rather than just throwing an HTTP 500)?  While I'd say consistency
is nice, that would raise the number of error types a client will
have to watch out for to three (HTTP-Level, global INFO, per-row
faults).  Hm.

I can't quite make up my mind what I'd like this to be.  What does
everyone else think on QUERY_STATUS policies (and on saying something
on MAXREC)?


       -- Markus