[redland-dev] Problems with SPARQL's OPTIONAL pattern matching

[Attilio Fiandrotti]

Arjan Wekking wrote:
>> Note that if the OPTIONAL keyword is removed, then Query 2 produces  
>> empty sets of result, but i never get crashes.
>> I suppose this is a bindings problem: is this analysis corect?

<snip>

> You are correct, it is a bindings problem and I encountered it a  while 
> back in the Python bindings (also with unbound nodes in  bindings 
> results). I opened a bug back then (http://bugs.librdf.org/ 
> mantis/view.php?id=59) and it has recently been fixed in CVS by Dave.  I 
> assume the same problem exists for the C# (and possibly other  language) 
> bindings, especially if I look at the relevant code (http:// 
> cvs.librdf.org/cvsweb/redland/bindings/csharp/QueryResults.cs? 
> rev=1.9&view=auto):
<snip>
> This is basically the same method as there is in the Python bindings,  
> here there is no check whether IntPtr v is null or not, assuming an  
> IntPtrcan be null in C# (never worked with it myself). What would be  
> required here (and possibly in other places) is a null check on 'v'  
> because most likely the Node constructor does not accept null values  
> (same thing in Python). So to fix it something like the following has  
> to be done:

Hi Arjan

thanks for the hint: in C# the patch would look like

Index: QueryResults.cs
===================================================================
RCS file: /cvsroot/redland/bindings/csharp/QueryResults.cs,v
retrieving revision 1.9
diff -r1.9 QueryResults.cs
41a42
 >                       Console.WriteLine ("DEBUG - MakeResultsHash () 
entered\n");
48c49,53
<                               h.Add (name, new Node (v));
---
 >                               if (v!=IntPtr.Zero) {
 >                                       h.Add (name, null);
 >                               } else {
 >                                       h.Add (name, new Node (v));
 >                               }


but this doesn't seem to fix the OPTIONAL bug: as the DEBUG message is 
never printed out, i guess MakeResultsHash() method is not involved in 
executing this query (unfortunately, i don't know  internals of redland, 
so ican't tell for sure).
What i got from a gdb session is (breakpoint on librdf_new_node_from_node)

624       LIBRDF_ASSERT_OBJECT_POINTER_RETURN_VALUE(node, librdf_node, 
NULL);
(gdb) bt
#0  librdf_new_node_from_node (node=0x81cb128) at rdf_node.c:624
#1  0xb6e82563 in ?? ()
#2  0x081cb128 in ?? ()
#3  0x00e3bf09 in ?? ()
#4  0x00000000 in ?? ()
(gdb) c
Continuing.
name => Dave Beckett

Breakpoint 7, librdf_new_node_from_node (node=0x0) at rdf_node.c:624
624       LIBRDF_ASSERT_OBJECT_POINTER_RETURN_VALUE(node, librdf_node, 
NULL);
(gdb) bt
#0  librdf_new_node_from_node (node=0x0) at rdf_node.c:624
#1  0xb6e82563 in ?? ()
#2  0x00000000 in ?? ()
(gdb)

in pure C the same query executed on the same document doesn't produce a 
call to librdf_new_node_from_node(NULL), only C#, so i suppose this can 
still be considered a bug in the C# port.
I'll try to dig deeper in this bug next week.

friendly

Attilio