Christian,
Thank you for your carefully considered and helpful suggestions, I will try them out first thing on Monday. Regarding RESTXQ, I had only really started to appreciate RESTXQ recently, while I was trying to get this server side query to run and I discovered that the admin functions (dba) were based on it. I will certainly look at RESTXQ too, potentially for also other "user interaction / reporting" aspects of our application, however, would like to see both methods work for completeness :-)
Mike
On Sat, Aug 6, 2016 at 1:12 AM, Christian Grün christian.gruen@gmail.com wrote:
Hi Mike,
o Am I fooling myself that creating a server side .xq file is going to perform better than building a completed query on the client and sending that via REST without "variables"?
Indeed it’s always recommendable to bind variables to a static expression instead of concatenating query strings (no matter if you are using our client bindings or REST). In terms of performance, there shouldn’t be any difference in BaseX, but your APIs will definitely be more robust and less prone to errors in the long term. Moreover, there’s no chance of query injection if you pass on dynamic user values.
o Is there a way to perform the equivalent "prepare/execute" method from the client without creating a .xq file on the server?
The usual way to go would be to pass on variables via the POST method and the <variable> elements. I see you have already found this alternative in our documentation.
o Can anyone suggest how I can get the server side .xq file to work?
First I thought “yeah, should be trivial”, then I noticed that I also stumbled upon the "no context found" error message. This is what I did:
URL: http://localhost:8984/rest/db?run=test.xq&driver=abc&contributor=def
XQUERY: declare namespace zss = 'your-zss-namespace-uri'; declare variable $driver external; declare variable $contributor external; delete node /zss:driver[@name=$driver]/zss:part[@contributor=$contributor]
To get this work, I had to include the database in the query:
URL: http://localhost:8984/rest?run=test.xq&driver=abc&contributor=def
XQUERY (in the server webapp directory): declare namespace zss = 'your-zss-namespace-uri'; declare variable $driver external; declare variable $contributor external; delete node db:open($db) /zss:driver[@name=$driver]/zss:part[@contributor=$contributor]
The database could obviously be passed on as query parameter as well.
I’ll send you another mail once I have found out why it’s not possible anymore to access the currently opened database inside your query.
However, I’d like to add another question to your three:
o Are there better ways to do this?
Yes: use RESTXQ :) It may take some more time to understand how it’s working, but it will allow you to specify much nicer APIs than REST.
Here is how your previous example would look like with RESTXQ:
URL (use the DELETE Method to delete data...): http://localhost:8984/db/abc/def
XQUERY (in the server webapp directory):
declare namespace zss = 'your-zss-namespace-uri'; declare %updating %rest:path("{$database}/{$driver}/{$contributor}") %rest:method("DELETE") function local:delete( $database as xs:string, $driver as xs:string, $contributor as xs:string ) { delete node db:open($database) /zss:driver[@name=$driver] /zss:part[@contributor=$contributor] }; ()
Hope this helps Christian