Hi Marco,
With the latest snapshot, the BINDINGS options will not be considered anymore when using xquery:eval (or with any other query sub process).
With regards to the general solution of binding external variables, it would be a bit more time consuming to realize a working solution: When external variables are initially registered in BaseX (via BINDINGS, via APIs, via REST, …), it is not clear yet if there will be any variable declarations for it in the query prolog. So all non-XQuery values will be cast to a specified target type, or (if none is specified) a type that results from the standard Java type bindings [1]. It would probably be better if non-XQuery values were only bound at compile time (we could then avoid converting a Java String as xs:string if the actual variable type is a number).
As indicated, maybe it already helps you if you switch to xs:integer. If you bind values via Java, you can additionally specify the XQuery target type [2,3].
Cheers, Christian
[1] http://docs.basex.org/wiki/Java_Bindings#Data_Types [2] https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/ba... [3] https://github.com/BaseXdb/basex/blob/master/basex-core/src/main/java/org/ba...
On Wed, Mar 21, 2018 at 4:57 PM, Christian Grün christian.gruen@gmail.com wrote:
Hi Marco,
Working with external variables can be tricky, and it’s difficult to explain all the intricate implications. But let’s try ;) First of all, I noticed the error messages differed in my tests, so please note I have used the latest snapshot (BaseX 9.0 RC4) for testing:
trying to understand why we get the exception [2] running the code [1] in a Java app
Could you possibly forward us the Java code as well?
xquery:eval(" declare variable $_dep as xs:long* external; $_dep[2] * $_dep[2]", map{ "_dep" : (1,2,3)})
obtaining the correct result (4).
This currently works, because external variables will first be cast to the target type. Ideally it should give you an exception, because the input is of type xs:integer, while it should be of type xs:long. For example, it’s correct that the following query gives you a type exception:
declare variable $v as xs:long := 1; $v
The following query is correct:
declare variable $v as xs:integer := 1; $v
I recommend you to use xs:integer whenever possible, because it’s the default XQuery type for integers (and BaseX internally uses long values for representing xs:integer anyway).
However, back to your example: xquery:eval currently raises no exception because we are currently using the same code for binding variables as we do for external clients – and the latter one is more liberal (because the client may not be written in XQuery, and may thus have different data types).
Anyway if I assign (1,2,3) to a binding through the proper dialog of the UI I get the following exception at execution:
Error: Stopped at /home/lettere/git/dasbox-frontend/dasbox-frontend-ui/webapp/ui/resources/js/monitoring/file, 2/12: [FORG0001] Cannot cast to xs:double: (1,2,3).
The reason here is that, right now, you can only bind single values via the bindings dialog…
Strangely enough this happens even if I leave the map overriding locally the values for the external parameters in the xquery:eval. The dialog wins?
…which will be bound to the global BINDINGS option [1]. Value assignments bound to this option will always override the values of external variable declarations. Maybe we should temporarily disable the values of this option while running a query, because I agree it makes no sense to have them bound within a nested xquery:eval call.
Ideally, I would like to see the BINDINGS options removed one day, because most global options are prone to side effects – especially in combination with runtime evaluation based on things like xquery:eval. On the other hand, various APIs would probably need to be extended.
Hope this helps. I’ll be happy to look at your Java code, and I’ll have some more thoughts on how we can make BaseX stricter without restricting external clients.
Christian