Sesame

On 27/09/11 04:57, George Garbis wrote:

> While checking sesame 2.5 implementation for SPARQL 1.1 Update I run
> into this problem:
>
> Assume that default graph has these triples:
>
>      ex:item1     ex:id "1"^^xsd:int .
>      ex:item1     ex:value "10"^^xsd:int .
>      ex:item2     ex:id "2"^^xsd:int ;
>      ex:item2     ex:value "20"^^xsd:int .
>
> And that the update below is executed:
>
>      DELETE { ?x ex:value ?y }
>      INSERT  { ?x ex:value ?y2 }
>      WHERE {
>          ?x ex:value ?y .
>          BIND( (?y+1) as ?y2) .
>          FILTER(?y<15) .
>      }
>
> After executing the update i expect that the triple
>      ex:item1 ex:value "10"^^xsd:int
> be replaced by the triple
>      ex:item1 ex:value "11"^^xsd:int
>
> However, the result is this:
>      ex:item1 ex:value "15"^^xsd:int
>
> It seems that while updating, sesame checks if new triples have to be
> updated, as well as old ones.
> So, the new value of item1 is increased by one, many times, until it
> reaches 15 and filter is no more satisfied.
> If FILTER(?y<15) is omitted the update will endlessly iterate because
> every new triple will be updated again and again.
> Has anyone else encountered such a problem?
> Is this the expected behaviour?

Peculiar. No, this is not the expected behavior, or at least, it's not 
the behavior as mandated by the spec. It is caused by the fact that we 
internally use lazy evaluation of the WHERE clause, and reuse the same 
connection - so it encounters newly added triples from the INSERT clause 
as it progresses.

I'll look into it. Thanks for reporting this.

Cheers,

Jeen

Minor update on this: I've managed to isolate and fix the problem. See 
issue SES-842 in the issue tracker. Fix will be included in the next 
release.

Jeen