Andy, Thank you for the time taken to point me in the right direction. Sorry to waste the list's time with something that (in retrospect) could have just as easily had been a StackOverflow post instead. With that in mind, I've moved my remaining questions over there (link: http://stackoverflow.com/q/22998628/2528639).
Much obliged, Rob On Thu, Apr 10, 2014 at 3:45 PM, Andy Seaborne <[email protected]> wrote: > On 10/04/14 17:46, Rob Hall wrote: > >> I apologize in advance if this is a duplicate: I could not find anything >> relevant on Jira. >> >> I came across what appears to be a bug when all 3 elements of a triple >> pattern for an INSERT clause are variables that have been assigned using >> BIND. After executing the UpdateAction, the desired triples are not >> introduced to the underlying graph. >> >> Attached is a small JUnit test case which reproduces this error. It can >> likely be further minimized. >> >> Regards, >> Rob >> > > > Rob, > > Looking at: > > " {\n"+ > " ?old ?p ?o .\n"+ > " BIND( ?old AS ?s ).\n"+ > " BIND( ?new AS ?ns ).\n"+ > " BIND( ?p AS ?np ).\n"+ > " BIND( ?o AS ?no ).\n"+ > " } > > ?new is not in-scope at that point - it does not flow in from the > sub-query higher up. Logically, each block is executed independently and > the results combined up the tree. The {SELECT} is executed, the UNION is > executed separately, then the results joined. > > So ?ns is not defined and hence the INSERT on "?ns ?np ?no" is not a legal > triple and is skipped (c.f. CONSTRUCT). > > Try executing the WHERE part as a SELECT * query to see more. > > Andy > -- Robert Trevor Hall Phone: (315) 719-5039
