Re: Return codes

On Thu, May 6, 2010 at 2:09 AM, Alexandre Passant
<alexandre.passant@deri.org> wrote:
> Hi,
>
> On 6 May 2010, at 03:55, Paul Gearon wrote:
>
>> The Update document now refers to result codes for each operation.
>>
>> A couple of things came up while I was doing this, and I would like
>> some feedback:
>>
>> - I have explicitly avoided stating what a result looks like, as this
>> is a job for the interface. I'd expect some kind of representation to
>> be used for SPARQL Protocol, HTTP operations, an API, and any other
>> type of interface.
>
> Would some HTTP codes for failure / success be defined in the protocol ?

Do you mean the SPARQL protocol? (as opposed to the HTTP protocol)

I was thinking that the SPARQL protocol would probably define
appropriate codes in the 5xx range, since the HTTP protocol has
already specified that those codes refer to a problem at the server
end. As for the extra information, that could be in a header or body,
but I'd have expected a header. (Though I've seen the note below about
updates)

>> - Most operations can fail partially or completely. To describe the
>> mode of failure I said that a failure can contain extra information,
>> and in most cases that will be an integer representing the number of
>> triples that were correctly processed. DELETE/INSERT is the one
>> exception to this, as a failure there includes a pair of tuples.
>> Presuming everyone is OK with this – should a complete failure be a
>> separate type again, or is a failure(0) sufficient? I have gone with
>> failure(0).
>>
>> - Going with the idea of failure data including the number of
>> successfully processed triples, I specified the failure of "DROP
>> GRAPH" due to partial deletion of data to include the number of
>> triples that were deleted. This makes sense to me, since the user can
>> always count whatever is left, but I just wanted to check that no one
>> wanted the failure to report the number of remaining triples instead.
>
> We decided (F2F3) to not indicate the number of triples added / deleted in Update [1] so we probably should stick to that.
> Counting the number of triples that left may also be cumbersome (e.g. if it deletes entailed triples, or if you simply forgot to check number of triples in the store before the query), even from the implementation side itself I guess.

Ah yes, I'd forgotten about not counting triples in an update, but I
recall it now. Thank you for reminding me. (personally, this will be
easier to implement, so I'm happy)

I'm still expecting to count the number of triples processed while
loading, right? You'll also notice that success does not carry any
extra information. Would it be useful for a successful LOAD to return
the number of triples loaded? It can be worked out in many cases by
doing a count before and after, but that's not guaranteed due to
redundant triples. On the other hand, I don't know how useful it is,
so I thought I should ask.

Regards,
Paul

Received on Thursday, 6 May 2010 17:44:20 UTC