Folks,
all I did was report a bug, and your response is to delete the whole
feature! This would completely throw out the baby with the bathwater and
may mean that we at TopQuadrant have to branch off to our own Jena
version when this happens.
I would be in favor of this option
5) Keep the API as it is and restore initial bindings for UPDATE as well.
It was IMHO a mistake to switch to parameterized queries. We make very
heavy use of initial bindings throughout our software stack, SPIN, SWP,
SPARQLMotion. They are a great feature, allowing users to treat SPARQL
like a programming language (think about a function call, where the
parameters are different each time, yet the developer only needs to
write the logic once).
From what I understand so far, parameterized SPARQL has performance
issues - we would need to re-parse the string while with initial
bindings we can reuse the same (compiled) Query object each time.
Parameterized queries also don't support the bound(?var) operator, and
probably others.
We have used initial bindings successfully for many years, and although
there have been occasional bugs (I probably reported one such bug per
year) it is a very essential feature from our point of view. If the
overhead of fixing the optimizer is too big, I would be OK with
switching off this optimizer if initial bindings are present. It worked
fine without this optimizer for many years.
HTH
Holger
On 8/3/2013 2:52, Rob Vesse wrote:
Hi All
Holger's question
(http://mail-archives.apache.org/mod_mbox/jena-users/201308.mbox/%[email protected]%3e)
about a regression in ARQs treatment of initial bindings raises an interesting
disconnect between the interpretation of SPARQL and the Initial Bindings API.
Initial bindings in their current form allows for users to essentially change
the semantics of a query in a non-intuitive way. Take his example query:
ASK { FILTER(?a = ?b) }
Intuitively that query MUST always return false yet with initial bindings in
the mix the query can be made to return true, at least prior to 2.10.2 which
introduces a new optimizer which includes special case recognition for this.
The problem is that using initial bindings can fundamentally change the
semantics of queries in non-intuitive ways when I believe the intention of the
API was merely to allow for improved performance by guiding the engine.
To me this suggests that initial bindings as currently implemented is
fundamentally flawed and I would suggest that we think about re-architecting
this feature in a future release (not the next release). I believe there are
probably several ways of doing this:
1 – Remove support for initial bindings on queries entirely (as we already did
for updates) in favor of using ParameterizedSparqlString
2 – Change initial bindings to be a pre-optimization algebra transformation of
the query
As we've discussed previously in the context of ParameterizedSparqlString there
is potential to do the substitution at the algebra tree level rather than at
the textual level. This allows for stronger syntax checking and actually
changes the query appropriately. The problem with this is that it doesn't work
if we want to inject multiple values for a variable, hence Option 3
3 – Change initial bindings to be done by injection of VALUES clauses
This approach is again by algebra transform and would involve inserting VALUES
clauses at each leaf of the algebra tree. So Holger's query with initial
bindings applied would be rewritten like so:
ASK
{
VALUES ( ?a ?b ) { ( true true ) }
FILTER (?a = b)
}
However this approach might get rather complex for larger queries and also runs
into issues of scope, what if we insert the VALUES clause inside of a sub-query
which doesn't propagate those initial bindings outside of it etc.
4 – Skip optimization when initial bindings are involved
This is the easiest approach but we can't enforce this on other query engine
implementations and it could seriously harm performance for those that use
initial bindings extensively.
There may also be other approaches I haven't thought so please suggest anything
that makes sense. Bottom line is that initial bindings in its current form
seems fundamentally broken to me and we should be thinking of how to fix this
in the future.
Rob
