The way that past versions of ARQ implemented initial bindings for updates is that the initial bindings were only fed into the WHERE portion of queries. Also this was not done via substitution., any restoration of initial bindings of updates would likely need to not use substitution. Although this may be moot because I don't know whether ARQ applies query optimization to WHERE portions of updates.
This meant that the variable having a value injected still existed in both the WHERE and template portions so if a blank node value is bound it is as if the value is simply copied from the WHERE portion to the template portion. Whereas with the ParameterizedSparqlString the behavior is substitution for a blank node so the template portion has a blank node in place of a variable hence generation of a new blank node rather than copying an existing one. Rob On 8/7/13 4:16 PM, "Holger Knublauch" <[email protected]> wrote: >On 8/8/2013 9:02, Rob Vesse wrote: >> Sorry I am snowed under with work atm. > >Sorry me too - working towards a release. > >> I have not tested but I would be >> tempted to enable and change the tests so that they reflect Holger's >> original regression test case. This would realign the behavior with >> previous versions of ARQ and fix the regression >> >> >> On a related topic I looked at Holger's question around injecting BNodes >> into SPARQL updates via ParameterizedSparqlString and it doesn't work in >> the scenario he describes (an INSERT WHERE) if the variable is used both >> in the INSERT template and WHERE since the template mention is treated >>as >> a minting a fresh BNode. Either he needs to use the BIND workaround >> discussed by yourself in another thread >> (http://markmail.org/message/3lsnjq7yca4es2wb) which I suspect is not >> workable for TQ OR we need to look at restoring initial bindings for >> updates. >> >> I think restoring the feature is going to be the best option, the >> documentation just needs to be really clear that initial bindings only >> apply to the WHERE portion of updates and not more generally since that >>is >> the only way they were used prior to the feature being removed (I went >> back and looked at the ARW 2.9.4 code). We can always look at expanding >> their scope later as we've discussed in the past. > >I would appreciate restoring this. I don't understand the last section >though - the scenario with pre-bound variables in the INSERT *did* work >in 2.9.2. It will be hard to explain to users that INSERT behaves >differently from CONSTRUCT. Furthermore, most examples of updates in our >code base either take URIs or bnodes as parameters, and if I understand >the limitation correctly then I would need to rewrite them all to copy >any variable with another BIND. > >Thanks, >Holger >
