[Mulgara-dev] Question about: INSERT/SELECT regression bug

[Andrae Muys]

On 01/11/2006, at 4:05 AM, David Moll wrote:

> One of the operations that we do a fair amount in Mulgara/TKS that  
> gives us a bit of a headache is doing modify/deletes.  Mainly  
> because we need to ensure that when deleting a triple, we don't  
> leave any "orphaned" triples lower on the graph.
>
> My end goal is to fully automate the ability to insert, modify and  
> delete information in the data store with a thin client that will  
> automatically generate the proper iTQL queries based on user  
> input.  In building up to this, I am trying to determine exactly  
> what queries I need to run in order to successfully modify  
> information in the data store.
>
> To "modify" I am performing an "insert" followed by a "delete."  I  
> created the following "insert" query:

If this is a common case, I would have thought it might make sense to  
use an existential and sameAs - this would reduce the problem to  
inserting and deleting one statement:

insert select <modifiedURI> <rdfs:sameAs> $n from <model> where  
<originalURI> <rdfs:sameAs> $n;
delete select <originalURI> <rdfs:sameAs> $n from <model> where  
<originalURI> <rdfs:sameAs> $n;

although granted as this is still an insert/select it doesn't avoid  
the bug discussed below.

> insert
>     select
>     <modifiedURI> $p $o
>     from <rmi://localhost/server1#model>
>     where <originalURI> $p $o
> into <rmi://localhost/server1#model>
> ;
>
> The inner select statement creates the triples that I want to  
> insert, but because <modifiedURI> is a "constant" to Mulgara/TKS,  
> it is assigned a negative node number.  So the result message is:

It's not that <modifiedURI> is a constant, rather it's that the URI  
doesn't already exist within the store.

> My question has two parts.
>
> Where are the values from NodePool assigned to the nodes created in  
> the select query?

 From the permanent and temporary StringPool/NodePool's.  The  
permanent NodePool returns +ve nodes, the temporary -ve.  When  
localizing a lookup is done against the permanent StringPool, and if  
that fails the temporary StringPool; if both fail then queries  
allocate a new node from the temporary NodePool (and insert it into  
the temporary StringPool), and inserts allocate from the permanent  
NodePool (inserting the mapping into the permanent StringPool).  The  
bug is that the query is still using the temporary pools despite  
being inside an insert.

Now I think about it, I suspect that the real problem is not that the  
bug is back, but rather that we may not have considered the issue of  
constants in the inner-select.  A work around would naturally be to  
do a known insert (maybe insert <modifiedURI> <rdf:type> <myclass>)  
before doing the insert/select - again this would have to be wrapped  
in autocommit's, and I fully admit it is ugly and shouldn't be required.

> Is there a reason that constants created in the "select" portion of  
> the above query are assigned negative node values?  It seems that  
> they could be assigned a new value from the NodePool, which would  
> allow for them to then be inserted into the data store.

Strictly speaking you are right - and indeed this is a regression  
(one I thought we fixed a while back).

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd