[Mulgara-dev] Blank Node Assignment in Inserts

Andrae Muys andrae at netymon.com
Thu Feb 28 04:33:16 UTC 2008


On 28/02/2008, at 1:37 PM, Life is hard, and then you die wrote:

> On Wed, Feb 27, 2008 at 08:20:48PM -0500, Alex Hall wrote:
>> It appears that the binding of variables to blank nodes when  
>> inserting
>> statements behaves differently depending on whether autocommit is  
>> turned
>> on for the session.  If I have autocommit turned on and execute the
>> following iTQL commands:
>>
>> create <rmi://localhost/server1#test>;
>> insert <test:subj> <test:pred> $x $x <test:value> 'o1'
>>     into <rmi://localhost/server1#test> ;
>> insert <test:subj> <test:pred> $x $x <test:value> 'o2'
>>     into <rmi://localhost/server1#test> ;
>> select $s $p $o from <rmi://localhost/server1#test> where $s $p $o;
>>
>> Then I see that the variable "x" is bound to different blank nodes in
>> each of the two insertions, and the resulting model has 4 statements.
>> This is the behavior (behaviour?) that I would expect.
>>
>> However, when I turn autocommit off prior to the first insertion, and
>> turn it back on after the second insertion, then I see that the  
>> variable
>> "x" is bound to the *same* blank node in each of the insertions,
>> resulting in 3 total statements in the model, which came as a bit  
>> of a
>> surprise to me.  Is this the expected behavior in that situation?
>
> Yup, this silently changed between 1.0 and 1.1 - blank-nodes node
> variables now have transaction scope instead of command scope. Paul
> and Andrae said this change was inadvertant and it should be changed
> back to the old behaviour, but no ones gotten around to doing so yet.
>
> Hmm, this should probably be filed as a bug.

Hmm, yes it probably should as I had completely forgotten this bug  
had been introduced, found, reproduced, and isolated - but just not  
recorded or actually fixed :).

I'll go and add the bug report now.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Senior RDF/SemanticWeb Consultant
Netymon Pty Ltd





More information about the Mulgara-dev mailing list