This is an interesting idea, if a bit complex. I'll try it out, but I can also simply create the various functions in the business layer, and then assemble queries as necessary.
Thanks!
Chas.
On 12/29/2010 10:48 PM, Mark Boon wrote:
A little while ago I asked something similar. Even when it's not a performance concern, then at least it very quickly gets to be a developer's concern when each query is lead by a huge amount of unused functions.
What I did was the following, functions are stored in a function element:
<function name='ar:A'> declare function ar:A ( $arg as xs:string ) as xs:string { let $result := collection()//variable[@name=$arg]/@value return ( if ($result) then $result/string() elsefn:concat('"',fn:concat($arg,' not found"')) ) } </function> <function name='ar:B> <use name="ar:A"/> declare function ar:B ( $arg as xs:string ) as xs:string { ar:A($arg) } </function>
and then when I call it:
<query> <use name="ar:B"/> ar:B('test') </query>and then I have an XSLT script that transforms the above by replacing the<use> element with the text-node of the<function> element with the same name at the time the XML file is read in. This is just an unrealistically simple example of course. It works for me because my queries are stored in an XML file. Otherwise you may have to invent a similar method for your particular need.
You may also want to check out the improved error-reporting I posted a few threads back.
Mark Boon(I hope GMail didn't mangle the formatting too much)
On Wed, Dec 29, 2010 at 6:32 AM, Charles F. Munat charles.munat@gmail.com wrote:
Good to know. I'm not worried about performance that much. I'm sure I can optimize the query(s) once I get them all figured out. What would have made the ability to store functions nice is that there are many that are reused in different queries, so currently I have to have multiple copies. Then if I make a change, I have to remember to make it to all of them. Not a big deal, just a matter of efficiency. But I can work around this on my end by storing the functions in one spot and then just inserting them programatically as necessary into the query.
When I get to optimizing, I will gladly take advantage of your offer. Huib has already given me some good ideas.
Chas.
On 12/29/2010 7:08 AM, Michael Seiferle wrote:
Hi Chas, (and hi Huib),
thanks for your input!
At the moment preloading& compiling queries ahead of time is not possible. The main reason for this is that, from our experience, queries are usually rather short and cheap to compile.
Providing an infrastructure that takes care of precompiled queries might present quite a challenge, yet it should not be impossible.
You two probably knew this, but it might be of interest to the list as well, there's a very basic benchmark mechanism:
SET RUNS N
Now every query you issue is run N-times, including parsing& compiling. You will get average duration values for each step, if you enable the query info view.
This is not representative, but on my machine the 40KB functx library [1] takes an avg of ~13ms to parse and ~7ms to compile, so the overhead introduced by reparsing/recompiling should be rather low in general.
In case you experience particular problems with specific queries feel free to contact us. Often tweaking the query a little, such that possible index optimizations are recognized correctly by our compiler will speed up queries considerably.
I hope this helps, feel free to ask for more! Feedback is very welcome :-)
Kind regards Michael
Am 29.12.2010 um 07:40 schrieb Charles F. Munat:
The other question I had was if it was possible to pre-load the embedded database with the functions, rather than having to load them all at the time the xquery is run. Sort of the way functions or triggers are preloaded into an RDBMS. Do you happen to know if that's possible?
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk