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
|