In my link management application I'm trying to refactor my code to move my link management metadata out of the content database (the one that otherwise has the user's XML docs) and into a separate database.
The problem I'm running into is that because db:create() is put last on the pending updates list, you can't do
return ( db:create('new-database'), db:add('new-database', '<some-data/>'))
There doesn't seem to be a direct way through the RESTXQ-managed application to create the database since updating functions don't return anything (so I can't, for example, have the root page handler ensure that the database is there simply by calling an XQuery function to initial it).
I think the only solutions are:
1. Have the database creation managed outside the REST application (e.g., in my git hooks, which are where the content database creation is done)
2. Use the redirect technique so that, for example, the root page is handled by an updating function that does the database initialization and then returns a redirect to the real root page handler.
Have I missed an option?
Thanks,
Eliot
---- Eliot Kimber, Owner Contrext, LLC http://contrext.com
Hello Eliot,
You can add the documents directly using the db:create() function, thus being able to create and initialize the database. If you have multiple documents to add it can be done like the following example:
db:create('new-database', (<some-data/>, <more-data/>), ("somedata.xml", "moredata.xml"))
Hope this helps, Dirk
On 07/11/2015 07:38 PM, Eliot Kimber wrote:
In my link management application I'm trying to refactor my code to move my link management metadata out of the content database (the one that otherwise has the user's XML docs) and into a separate database.
The problem I'm running into is that because db:create() is put last on the pending updates list, you can't do
return ( db:create('new-database'), db:add('new-database', '<some-data/>'))
There doesn't seem to be a direct way through the RESTXQ-managed application to create the database since updating functions don't return anything (so I can't, for example, have the root page handler ensure that the database is there simply by calling an XQuery function to initial it).
I think the only solutions are:
- Have the database creation managed outside the REST application (e.g.,
in my git hooks, which are where the content database creation is done)
- Use the redirect technique so that, for example, the root page is
handled by an updating function that does the database initialization and then returns a redirect to the real root page handler.
Have I missed an option?
Thanks,
Eliot
Eliot Kimber, Owner Contrext, LLC http://contrext.com
I took my option (1) and now have my commit hooks ensure that the database exists, which was easy enough to do (just needed to add an addition CHECK command to my existing BaseX command sequence). It just means that the RESTXQ code itself can't ensure that the metadata database is up to date, at least not without some significant refactoring, which I probably need to do but don't have scope for at the moment.
The problem in my case with doing the create and add at once is that there is quite complex business logic involved in creating the documents, so they're not something that can be conveniently created, held in memory, and then committed at once (I could have implemented the processing that way but it's definitely not the natural way to do it).
Basically I'm building a metadata cache to optimize queries that would be hard to do by brute force. The number of documents to be created and added could be quite large.
As a cache you'd like to be able to have it created or updated on demand--e.g., if I request an operation that requires the cache, the first thing you do is see if the cache is up to date and, if not, create or update it.
But with XQuery's constraint on when you can do updates that's not possible, at least not in a naïve way--if you have a function that needs to return a result it cannot also do updating (meaning it can't call any updating functions).
I understand the reasoning for that restriction but it is an annoying constraint.
In my case my problem is a little easier because the whole BaseX database is really a cache of what's in a separate git repo, so any time the git repo is updated (new commit or new branch creation or check out) I refresh the BaseX database and can regenerate my cache at that time, so it's not a big deal, just a mismatch between how I would do things in e.g., a Java application and how they have to be done using RESTXQ.
I have looked at the DBA code but I was having a hard time understanding exactly what it was doing in the short time I had to work on it (although I did see what it was doing with db:output() and redirection).
Cheers,
Eliot ---- Eliot Kimber, Owner Contrext, LLC http://contrext.com
On 7/13/15, 2:59 AM, "Dirk Kirsten" <basex-talk-bounces@mailman.uni-konstanz.de on behalf of dk@basex.org> wrote:
Hello Eliot,
You can add the documents directly using the db:create() function, thus being able to create and initialize the database. If you have multiple documents to add it can be done like the following example:
db:create('new-database', (<some-data/>, <more-data/>), ("somedata.xml", "moredata.xml"))
Hope this helps, Dirk
On 07/11/2015 07:38 PM, Eliot Kimber wrote:
In my link management application I'm trying to refactor my code to move my link management metadata out of the content database (the one that otherwise has the user's XML docs) and into a separate database.
The problem I'm running into is that because db:create() is put last on the pending updates list, you can't do
return ( db:create('new-database'), db:add('new-database', '<some-data/>'))
There doesn't seem to be a direct way through the RESTXQ-managed application to create the database since updating functions don't return anything (so I can't, for example, have the root page handler ensure that the database is there simply by calling an XQuery function to initial it).
I think the only solutions are:
- Have the database creation managed outside the REST application
(e.g., in my git hooks, which are where the content database creation is done)
- Use the redirect technique so that, for example, the root page is
handled by an updating function that does the database initialization and then returns a redirect to the real root page handler.
Have I missed an option?
Thanks,
Eliot
Eliot Kimber, Owner Contrext, LLC http://contrext.com
-- Dirk Kirsten, BaseX GmbH, http://basexgmbh.de |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
Thanks for the background information.
But with XQuery's constraint on when you can do updates that's not possible, at least not in a naïve way--if you have a function that needs to return a result it cannot also do updating (meaning it can't call any updating functions).
I understand the reasoning for that restriction but it is an annoying constraint.
Indeed it is. The implementation of the XQuery Scripting Extension [1] would have been one way out, but due to its complexity, the Zorba guys were the only ones that ever implemented it. One other way would have been to ignore the constraints of the official specs, but we decided to stay compliant. One more solution – at least for your requirement to have updating functions that can return items – is our MIXUPDATES option (see [2] for more details).
Ironically, in our own code, we don't stumble across this restriction very often, probably because have already got used so much to the redirection pattern. Version 3.0 of the W3 XQuery Update Facility may provide a construct that will render our db:output extension obsolete.
Christian
[1] http://www.w3.org/TR/xquery-sx-10/ [2] http://docs.basex.org/wiki/Options#MIXUPDATES
Hi Eliot,
additionally to Dirk's hint, I'd like to point you to our DBA RESTXQ code. It contains many examples on how to perform updates exclusively with the BaseX extensions of XQuery.
Best, Christian
On Sat, Jul 11, 2015 at 7:38 PM, Eliot Kimber ekimber@contrext.com wrote:
In my link management application I'm trying to refactor my code to move my link management metadata out of the content database (the one that otherwise has the user's XML docs) and into a separate database.
The problem I'm running into is that because db:create() is put last on the pending updates list, you can't do
return ( db:create('new-database'), db:add('new-database', '<some-data/>'))
There doesn't seem to be a direct way through the RESTXQ-managed application to create the database since updating functions don't return anything (so I can't, for example, have the root page handler ensure that the database is there simply by calling an XQuery function to initial it).
I think the only solutions are:
- Have the database creation managed outside the REST application (e.g.,
in my git hooks, which are where the content database creation is done)
- Use the redirect technique so that, for example, the root page is
handled by an updating function that does the database initialization and then returns a redirect to the real root page handler.
Have I missed an option?
Thanks,
Eliot
Eliot Kimber, Owner Contrext, LLC http://contrext.com
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Dirk Kirsten -
Eliot Kimber