| Feed Contents | |||
|---|---|---|---|
| Restart DB without killing the JVM | by wolf | 22-4-2009 13:23 | |
| Standalone XQuery Engine | by wolf | 31-1-2009 22:53 | |
| XQuery Debugger API | by adam | 1-1-2009 22:06 | |
| XQuery Dependency Analysis | by adam | 16-12-2008 16:44 | |
| Use range index to speed up distinct-values | by wolf | 3-12-2008 17:39 | |
Restart DB without killing the JVM
eXist can be shut down via the admin webapp or the Java client. However, there's no way to bring it up again unless you restart the Java virtual machine.
It would be good to have a "reload" command, which cleanly shuts down eXist and restarts it immediately after. The command would need to trigger a class which resides outside of the XQuery engine, maybe via the job scheduler. This class could then shut down and reload eXist.
- 0 Comments
- Add Comment
Standalone XQuery Engine
Allow eXist's XQuery engine to be used without a database, e.g. for evaluating a query on the command line. This is basically possible, but we need to make sure that all functions which require a database throw an error which is clear to the user. This could probably be done by creating a dummy DBBroker instance whose methods are either empty or throw an exception.
XQuery Debugger API
At present there is no simple way to debug XQuerys running in eXist.
Debug capabilities need to be provided to support facilities such as: breakpoints, watches, local variables, stack traces and execution control (step-in, step-out, step-over, run to cursor).
It seems that each IDE or tool has its own API for debugging and as such a plugin for each must be developed. eXist may typically run in one of two modes - embedded or server.
When eXist is running as a server a protocol is needed to talk between the IDE plugin and the eXist server, this protocol should be the same for all the plugins and it would be prudent to use a known existing open protocol such as JDWP or DBGP. Whichever protocol we choose it must be able to support the debugging facilities of all the IDE's. Only as a last resort if the other options are considered unsuitable should we then consider developing our own debug protocol.
When eXist is running embedded the same protocol API could be used in-memory to communicate between the plugin and eXist.
oXygen
oXygen XML Editor provides an XQuery debugger that supports a number of popular XQuery processors such as Saxon. it would be advantageous to be able to use this with eXist.
Eclipse IDE
XQuery Development Tools is an effort to try and integrate XQuery development into Eclipse. It makes use of its own custom protocol.
There is also the XQuery Development Tools in the Eclipse Web Tools Incubator, that could be used.
The XSL Tools incubator at Eclipse, could be used to see how to hook into the Eclipse Debug framework, and possibly make it extensible.
Other
This attempt at a specification for a debugging protocol could also be of interest - http://www.xdebug.org/docs-dbgp.php This debugging protocol has already an eclipse client with DLTK (dynamic language toolkit: http://www.eclipse.org/dltk/).
XQuery Dependency Analysis
A method to analyze an XQuery at compile time for the dependencies on objects in the query. If parts of the query could be described in a dependency tree, rather than the query being executed in a linear fashion we could do some out-of-step parallel execution of the query and then recombine the results for delivery.
Use range index to speed up distinct-values
The distinct-values function could use existing range indexes.
