On Aug 8, 2008, at 3:26 PM, Seaborne, Andy wrote:
* For the SPARQL community, BSBM sends the message that one ought to
support parameterized queries and stored procedures. This would be
a SPARQL protocol extension; the SPARUL syntax should also have a
way of calling a procedure. Something like select proc (??, ??)
would be enough, where ?? is a parameter marker, like ? in
ODBC/JDBC.
I presume you mean ??var1, ??var2, i.e. named parameters?
Also a great idea and maybe something Ivan does not have on his list
yet.
SPARQL already has parameterized queries! Because it has explicit
(named) variables, these can be used to set variables scoped just
outside the query string.
Except that there's no way (I know of) to do that setting. Could you
give an example? Also, there's no standard way to precompile/prepare
the query, obviating the benefit of having a parameterized query in
the first place. Unless I'm missing something in the spec (which I
would be pleased to discover).
The ODBC /JDBC approach of positional parameters, and this is named
parameters. Semantics is it like joining in a one row table
(because you can think of variables in graph patterns as set-once
assignments that allow reassignment of th eame value but not a
different value.
There is an issue of whether the parameterisation is applied client
or server side. If client side, no protocol changes are needed.
It is a burden on a client do some level of parsing to correctly
substitute parameters but I think it's just a (non-trivial) regex
as it only has to deal with variable-like syntax outside strings
(c.f. the canonical JSON regex to check for safe javascript). That
means even simple clients that don’t do much more than build/send
SPARQL strings are still possible. No parser necessary.
Adding to the protocol might be nice but it's not a showstopper.
Not having it in the standard/protocol is like not having it.
This has worked well in ARQ, for RDQL and SPARQL for a while.
Sure, and lots of people (including me) have done similar for SQL. I
solves some problems (e.g. constructing queries that are
implementation dependent, ability to do object relational mapping
without explicit db support), but not others (e.g. avoiding the cost
of compiling a query for frequently used queries).
ARQ has had stored procedures for a while. Property functions (with
lists for subject and or object) seem to be preferred because it
remains within strict SPARQL syntax.
Example please, as I'm not following what you mean.
They do get messy if the match to the S-list/P/O-list form is not
natural. Property functions don’t allow for expressions.
An example where it is messy would help too.
Best,
Alan
