Erlang XQuery 3.1 processor and XML database
New to Erlang?
See the Getting Started section
What is xqerl?
xqerl is a self-contained XQuery 3.1 processor and XML database written in Erlang.
- xqerl can be embedded in Erlang or Elixir applications or used as stand-alone.
- A small example of embedding XQuery into Erlang can be found here.
- User code is written in XQuery.
- XQuery code is compiled into BEAM (the VM that runs Erlang, Elixir, and others).
- xqerl can use REST to talk to the outside world. REST end-points are defined by the user using XQuery and RESTXQ annotations.
xqerl is being actively developed and does not have a stable release yet. Changes may occur without notice. If you save data with it, that data may not be compatible with the latest version of this repository in the master branch.
The first stable release is coming soon, but is not complete yet.
it is passing 100% Of 30,895 Test Case It runs. Another 1,823 cases testing optional features or unsupported specification versions have been discarded. Most of the test cases run are from the W3C QT3 test suite for XPath and XQuery. Others are from the EXPath test suite and the updated feature test suite for version 1.0.
module
The statically available modules for XQuery code in xqerl are documented in the xqerl documentation
The features it has
It does not have such features
- Schema Aware and Typed Data Features
- full-text extension
using the
There is no good GUI or web interface. If you need this, you may want to try one of the other XQuery processors that have these features. But since it follows the implementation specification, code written in any other conforming processor should work fine here. A GUI may come eventually, but it will take some time and a lot of effort.
There is also no web-based administration tool. Eventually this will also be added.
The main idea with xqerl is to take XQuery code that works in other processors and turn it into scalable, concurrent Erlang applications.
xqerl compiles all code before use. That is, it does not compile on-the-fly. To compile an XQuery module from a file, use this: xqerl:compile(FileName)value returned from xqerl:compile(FileName) Call is an atom with the name of the module. This is the atomic Erlang module name, and can be used to call the main module. For example:
(xqerl_node@127.0.0.1)1> M = xqerl:compile("/home/coolperson/coolModule.xq").
file____home_coolperson_coolModule_xq
(xqerl_node@127.0.0.1)2> xqerl:run(M, #{}).
The map parameter is an external reference passed to the query. This is where external variable values and reference-items can be set.
The return value will depend on the serialization parameters in effect in the source file. With no parameters, an Erlang word will be returned. With the serialization method, a binary with the serialized return value will be returned.
Library modules must also be pre-compiled before use. Also, modules that have dependencies must be compiled from bottom to top, i.e., modules with no imports first.
loading data
Use this to load data into the database xqldb_dml:insert_doc(DocUri, Filename) Celebration. As the parameter names indicate, the first parameter is the URI that will be used in the functions. fn:doc Or fn:collectionAnd the second value is the absolute file location to insert. Deleting data is done with the function xqldb_dml:delete_doc(DocUri),
building
rebar3 is the best way to build xqerl (and its dependencies) from source. In the future, release packages will be bundled for easier installation.
ongoing trials
rebar3 ct --spec "test/test.specs"
Contribution
Yes, please. I’m doing this alone, so any help would be greatly appreciated. This doesn’t just mean hacking Erlang, but can also include adding documentation, tutorials, or opening an issue for something you think is missing or would be a really cool thing to include.
Or perhaps you’re more of a social-media type? Contact us on Twitter @xqerl,
There’s also a Slack workspace named… you guessed it! xqerl.slack.com,
Work
- a query-rewrite step
- A cost-based implementation that could be run at the database level would be nice
- Moving Nuclear Operators to Rust NIF (Petaurista)
- Indexes can be added for more common access paths to data
…and possibly other things…
See “Contributions”