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

[Paul Gearon]

Hmmm, interesting problem.  I wasn't aware of this one.  I've been  
lucky until now, as my insert-select statements which use a constant  
will always use URIs which already exist.  That's a nasty gotcha though.

On Oct 31, 2006, at 12:05 PM, 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."

Yes, this makes sense.

>   I created the following "insert" query:
>
> 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:
>
> org.mulgara.query.QueryException: Unable to modify rmi://localhost/ 
> server1#model
>
> And the stack trace is:
>
> 2006-10-31 11:09:39,333 WARN  [RMI TCP Connection 
> (249)-192.168.10.205] store.StatementStoreResolver - Note: if any  
> of the query nodes are negative this is a known bug [ 1089540 ]  
> INSERT/SELECT regression in sourceforge
> <snip>
> Caused by: org.mulgara.query.QueryException:  
> org.mulgara.store.statement.StatementStoreException: Attempt to add  
> a triple with node number out of range: -1 2 1808329 39
>  at org.mulgara.store.statement.xa.XAStatementStoreImpl.addTriple 
> (XAStatementStoreImpl.java:441)
>  at org.mulgara.resolver.store.StatementStoreResolver.modifyModel 
> (StatementStoreResolver.java:363)
>  ... 18 more
> I cut out most of the stack trace, I didn't think it was that  
> important to the issue.  I found the listing on Sourceforge   
> (http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1089540&group_id=89874&atid=591704).  Then I went  
> to XAStatementStoreImpl.java to investigate what was happening.  I  
> added the method from XAStatementStoreImpl.java where the exception  
> occurs below.
>
> My question has two parts.
>
> Where are the values from NodePool assigned to the nodes created in  
> the select query?
> 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.

Both questions get answered in the same part of the code.

The insert will call StringPoolSession.localizeSPObject 
(spObject,flags) on the URI.  This is the code that requests a gNode  
for the given URI.  In this case, the "flags" param is set to TEMP,  
while you need it set to (WRITE | PERSIST).

It's possible to find the code path leading up to this point from an  
insert-select.  But if it were me, I'd find it by putting a  
breakpoint there, or dump a full stack trace into the log.  :-)
(Try a break point at src/jar/resolver/java/org/mulgara/resolver/ 
StringPoolSession.java:532)

Once found, it should be possible for insert-select versions of the  
query to override the flags.  My only concern is when the source and  
destination models are on different machines, but I guess it's not  
such a problem since Mulgara isn't supporting that right now.

As a temporary workaround, perhaps you could put in an rdf:type  
statement about the new URI?  That would guarantee that the node  
exists in the StringPool.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mulgara.org/pipermail/mulgara-dev/attachments/20061101/1f261d71/attachment.html