Hi Chris,
Our situation is that we have multiple client applications in various languages that will connect to a database.
Are you already using some of the clients that are available for communication with the BaseX client/server architecture [1], or are (planning to) communicating with the HTTP server?
In the first case, or if you use HTTP with the basic REST API, it’s recommendable to give your users access to this specific database [2]. You could then store all queries on the server, and launch them via the RUN command [3] or the equivalent REST 'run' operation [4].
In the second case, and if you decide to write a RESTXQ application, you will have full flexibility, as you control in your server-side entry point which database is to be opened and accessed [5]. As indicated by Steve, you can use xquery:eval [6] to address and evaluate queries that are either organized as static strings, stored in the file system or stored in a database (possibly a separate instance that contains only queries).
Compared to most relational DBMS, BaseX is much more light-weight, and startup time is minimal. If you have a limited number of database that you want to provide, it’s perfectly ok to launch a number of BaseX instances. I remember a use case in which we had deployed 12 BaseX instances on a single server, mostly because we wanted to simulate horizontal scalability.
Personally, I would recommend the RESTXQ approach, but it also depends on how much time you want to invest in writing more complex XQuery applications.
Cheers, Christian
[1] http://docs.basex.org/wiki/Clients [2] http://docs.basex.org/wiki/User_Management [3] http://docs.basex.org/wiki/Commands#RUN [4] http://docs.basex.org/wiki/REST#GET_Method [5] http://docs.basex.org/wiki/RESTXQ [6] http://docs.basex.org/wiki/XQuery_Module#xquery:eval
On Mon, Feb 24, 2020 at 6:22 AM DYER Chris Chris.Dyer@sydac.com wrote:
Hi Steve,
I do not think what we are trying to achieve is necessarily OO related (although I can see why it may look that way).
It may be more that we would be looking at another layer of encapsulation of some basex features.
Your suggestion on storing the queries within the database and then evaluating them does sound like a possible option for us. It would be nice to achieve this scoping of the queries using explicitly registered function modules.
This is all based on what we are currently achieving with our oracle database solution.
We have a single oracle database server, and we have developers create new user spaces on that server which encapsulates a set of tables and associated stored procedures (functions) for working with those tables. Those functions are only visible within the scope of the user space
It sounds like this sort of use case would generally be handled with separate basex installs/servers.
So I am possibly looking at a feature request.
Cheers, Chris
From: Majewski, Steven Dennis (sdm7g) sdm7g@virginia.edu Sent: Saturday, 22 February 2020 12:37 AM To: DYER Chris Chris.Dyer@sydac.com; basex-talk@mailman.uni-konstanz.de Cc: Markus Wittenberg wittenberg@axxepta.de Subject: Re: [basex-talk] Database specific xquery modules
I’m not sure this is the best approach, but you seem determined to try to figure out how to turn XQuery into an Object-Oriented language, so, if you want to bind query functions to a particular database, you can put the functions in the database, and use xquery:eval()
http://docs.basex.org/wiki/XQuery_Module to call the function as a node() argument to eval.
You would be using the context database as the “self” variable and xquery:eval() as dispatcher.
If you don’t literally want to bind functions to DB, but instead dispatch by the schema of the data, you could use a typeswitch if the schema have different namespaces or root elements,.
( I’ve tried this to switch between processing TEIP4 and TEIP5, for example. )
— Steve M.
On Feb 21, 2020, at 1:41 AM, Markus Wittenberg wittenberg@axxepta.de wrote:
If you want to use RESTXQ you would have to put the modules, or least the functions defining the endpoints, in the webapp directory and not in the repo directory. And far as I know, BaseX doesn't support installation for modules in webapp as for in repo. So you have to explicitly change/add files in webapp directory.
You could write a module for each database, defining its own endpoints, and maybe still reuse some code by importing a module with common functions in every specific module.
Am 21.02.2020 um 07:11 schrieb DYER Chris:
Hi Markus,
Not quite what I am aiming for.
We do want a single BaseX Instance to provide access to multiple databases.
Further to this though, a set of client applications will only connect to one database. We have multiple sets of client applications, with each set each connecting to one database.
We do want to modularise the functions, however as an example we want to be able to have 2 versions of the same function, where 1 version works with the schema of the data in database 1, and the second version with a different schema in database 2.
If I could explicitly link the function modules with a database, I could call the same function from both application sets, and use the context of the open database to call the correct version of the function.
An example situation may help
Say we have Database for “Black Books”, which has book data in xml structures which conform to some version (1.1) of a schema.
We want a query stored on the server that returns books on art
Get-Books-About-Art
We have a client application specifically for this database that calls this function.
It will only need to query the data in this database.
Now we add a second Database for "Goliath Books"
The book data in this database uses a modified xml structure (version 2 of a schema)
We have a client application for this database that also wants to get books about art.
The query for this database is slightly different because the xml schema has changed.
I would like to store both versions of Get-Books-About-Art in the database.
Then for each client to connect to their associated database, and be able to execute the correct version of the xquery function.
The idea is that each time I add a new database that has data in some format, I can install associated query modules that are restricted to the context of that database to avoid conflicts with existing databases.
Maybe what I am looking for is effectively a database specific repo to install modules to, rather than a basex install repo.
From: Markus Wittenberg wittenberg@axxepta.de Sent: Friday, 21 February 2020 2:15 PM To: DYER Chris Chris.Dyer@sydac.com; basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Database specific xquery modules
A RESTXQ definition could look something like this:
declare
%rest:path("/a/{$client}/{$path}")function yourmodule:test($client as xs:string, $path as xs:string) {
let $db := switch ($client) case "clientA" return db:open("dbA") case "clientA" return db:open("dbA") default return db:open("dbX") return yourmodule:do-something-with($db, $path)};
And the called function do-something-with could also depend on the client
Am 21.02.2020 um 03:48 schrieb DYER Chris:
Hi Markus,
Our intent is to use REST and RESTXQ interfaces to interact with data on a single database using some server side XQueries.
However, we may have 2 (or more) databases provided by some server, and associated xqueries are specific to the contents of each database (as the contents of each of these databases may be structured differently).
We would like for a client to be able to open a single database and be able to run associated XQueries, without requiring client side knowledge of which server side xqueries are associated with the database it has opened.
Does this help describe what we are trying to achieve?
Cheers, Chris
From: BaseX-Talk basex-talk-bounces@mailman.uni-konstanz.de On Behalf Of Markus Wittenberg Sent: Friday, 21 February 2020 12:08 PM To: basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Database specific xquery modules
Hi Chris,
as you might already know, BaseX has built-in REST support [1] which you can use to query and update data via HTTP. You can also use the RESTXQ [2] functionality to define arbitrary server side XQueries which can also be requested by HTTP and are also suitable for web applications. Both methods are not restricted to a single database.
Best regards,
Markus
[1] http://docs.basex.org/wiki/REST
[2] http://docs.basex.org/wiki/RESTXQ
Am 21.02.2020 um 02:05 schrieb DYER Chris:
I am looking for some ideas on some architecture surrounding xquery modules.
Our situation is that we have multiple client applications in various languages that will connect to a database.
We will have some reasonably complex xqueries to extract data in certain structures that will be used by each of these clients.
So to avoid having to duplicate the query logic we would like the xqueries to reside "in" the database.
Additionally, we would like to use the same BaseX installation for multiple databases, corresponding to multiple projects.
The data in each of these databases may be against a different schema and our xqueries are essentially tied to the schema of the data. Thus, each database may need slightly different xqueries.
The xquery library modules looks to be global for the BaseX instance, as does the loading of main modules off of disk.
Is there any way to tie the query module or file to a specific database?
We are trying to avoid being limited to 1 database per BaseX instance.
An alternative would be to embed the xqueries within our client applications, but that involves duplication. Also, we are not sure if there are any performance difference with having the queries stored in the repo vs client side?
For background, we are looking at migrating from oracle to BaseX. So, we are effectively looking for an equivalent of multiple clients connecting to a userspace and using stored procedures which are specific to that userspace.
Any ideas on how to achieve this currently? Or is this something that BaseX could support?
Cheers,
Chris
--
Markus Wittenberg
Tel +49 (0)341 248 475 36
Mail wittenberg@axxepta.de
axxepta solutions GmbH
Lehmgrubenweg 17, 88131 Lindau
Amtsgericht Berlin HRB 97544B
Geschäftsführer: Karsten Becke, Maximilian Gärber
--
Markus Wittenberg
Tel +49 (0)341 248 475 36
Mail wittenberg@axxepta.de
axxepta solutions GmbH
Lehmgrubenweg 17, 88131 Lindau
Amtsgericht Berlin HRB 97544B
Geschäftsführer: Karsten Becke, Maximilian Gärber
--
Markus Wittenberg
Tel +49 (0)341 248 475 36
Mail wittenberg@axxepta.de
axxepta solutions GmbH
Lehmgrubenweg 17, 88131 Lindau
Amtsgericht Berlin HRB 97544B
Geschäftsführer: Karsten Becke, Maximilian Gärber