Re: Updates

On Thu, Dec 3, 2009 at 6:02 AM, Steve Harris <steve.harris@garlik.com> wrote:
> On 3 Dec 2009, at 10:27, Andy Seaborne wrote:
>>
>> On 01/12/2009 17:23, Paul Gearon wrote:
>>>
>>> On Tue, Dec 1, 2009 at 8:58 AM, Andy Seaborne<andy.seaborne@talis.com>
>>>  wrote:
>>>>
>>>> I confess I don't see the arbitrary order of INSERTs and DELETEs as very
>>>> clear.  Is there a reason for multiple INSERTs and DELETEs, and allowing
>>>> INSERTs before DELETEs?
>>>
>>> The request seems to have two motivations, both based on modifying
>>> more than one graph at a time. The first is that it provides a syntax
>>> for specifying several graphs (though allowing "GRAPH<uri>  {...}"
>>> into the template would also provide this).
>>>
>>> The second was to address public concerns that we've had about lack of
>>> transaction support. This didn't make it into the mailing list, but we
>>> were grilled on it at ISWC. The most vocal concern came from Abraham
>>> Bernstein. Should I ask him to write something formal? (I'm surprised
>>> he hasn't already).
>>
>> There are several aspects to providing transactions.  If we are addressing
>> transactions, then we need to decide what the problem space we are
>> addressing. We seem to be in similar position to query here - there are many
>> features so either we take longer and do more, or shorter and expect a later
>> WG to continue the work.  We need to decide explicitly on the scope.
>>
>> Having a single block of INSERT/DELETEs ties to a single WHERE isn't
>> general. Was having explicit BEGIN-COMMIT/ABORT words with a per-service
>> declaration of what they mean considered?
>
> My impression was that Abraham wanted transactions with defined semantics,
> as per SQL.

Yes, and I believe we said, "No way that will happen this time
around." Or words to that effect. He was certainly unhappy.

However, it did serve to create interest in a more capable operation
that can be considered atomic. Sure, it doesn't have the flexibility
of a complete transaction, but for smaller scoped projects it is
certainly adequate. I believe that's been the motivation behind much
of this.

Now that Andy has opened my eyes to the possibility of multiple
operations in a single request, then I'm left wondering if that might
just do instead. The grouping then gets pushed to the protocol level,
and we insert language saying that multiple operations SHOULD (or MAY)
be atomic. (Hmmm, yet another capability to add to the SD document.
Greg won't like me)

Regards,
Paul

Received on Thursday, 3 December 2009 17:28:14 UTC