Hi Andy,
thx, I got it. Now it's running. But if in the query is an imported namespace, for example
import module namespace kleist = "http://kleist-digital.de/ns/kleist" at "../modules/kleist-functions.xqm";
then with
curl -i "https://xxx-xxx.rhcloud.com/rest?run=xqs/list_ba_flyer.xq"
I'll get
Could not retrieve module: /var/lib/openshift/xxx/app-root/modules/kleist-functions.xqm
I tried a lot of path-variations for " at '../modules/kleist-functions.xqm' ", but none succeeded.
The file-structure is as following: - webapp -- modules ---kleist-functions.xqm -- xqs --- list_ba_flyer.xq
Thanks for any advice.
One more thing, hopefully the last one ;-)
My data are changing a lot, so I have to recreate my basex-db again and again. Locally it's no problem, I'm doing it with BaseX GUI. But is there a convenient way for doing it with the remote server? Like changing the data in the folder first-data and the db will be recreated after pushing it to the server. Or do I have to re-install the whole app after changing the data?
Thanks a lot for your advices, Best, Günter
Am 31.03.2016 um 19:45 schrieb Andy Bunce bunce.andy@gmail.com:
Hi Günter,
I also copied my xq-files via repo On the Server the file is copied to /var/lib/openshift/xxx/app-root/data/basex/repo/xqs/list_ba_flyer.xq
I think using repo is the problem. This is intended for special packages and modules only.
If you look at the right side of dba/databases page you should see something like:
REPOPATH /var/lib/openshift/56fc4cce2d5271f290000121/app-root/data/basex/repo RESTPATH RESTXQPATH .. WEBPATH /var/lib/openshift/56fc4cce2d5271f290000121/app-root/data/basex/webapp
For resolving REST run paths RESTPATH is used. This is unset in the default configuration - so WEBPATH is used (see http://docs.basex.org/wiki/Options#RESTPATH )
So if you create a xqs folder below webapp and put list_ba_flyer.xq there then it should work.
Regarding the database loading zips my documentation is again a bit lacking here. I meant if you have created a basex database backup using the dba or the gui and place the resulting zip here. (The name would look like factbook-2016-03-31-18-19-09.zip ) then it could be restored from the dba. I would not expect a zip of the sources to work.
/Andy
On 31 March 2016 at 17:53, Günter Dunz-Wolff kleist@mail.dunzwolff.de wrote: Hi Andy,
great work. I've tried it, and everything went as expected. With a simple factbook-db I only got one error. If you are loading the first-data as factbook-db as .zip-file, you'll get the following error when loading: https://xxx-xxx/dba/databases
Problem accessing /dba/databases. Reason: Stopped at /var/lib/openshift/56fd326b89f5cf2ec200002e/app-root/data/basex/webapp/dba/modules/html.xqm, 282/70: [FORG0001] Wrong xs:dateTime format: 'factbook' (try e.g. '2000-12-31T23:59:59.999'). Stack Trace:
- /var/lib/openshift/56fd326b89f5cf2ec200002e/app-root/data/basex/webapp/dba/databases/databases.xqm, 79/30
- /var/lib/openshift/56fd326b89f5cf2ec200002e/app-root/data/basex/webapp/dba/databases/databases.xqm, 30/10
If you are loading the factbook-db unzipped, everything works.
That's also true with my own db. I also copied my xq-files via repo, but I don't know, how to access them via REST-Interface. On my local machine I'm able to cUrl via curl -i "http://localhost:8984/rest?run=xqs/list_ba_flyer.xq"
With the remote Server I'll get "Resource "xqs/list_ba_flyer.xq" not found." with corresponding curl -i "https://xxx:xxx@xxx-xxx.rhcloud.com/rest?run=xqs/list_ba_flyer.xq" curl -i "https://xxx-xxx.rhcloud.com/rest?run=xqs/list_ba_flyer.xq"
On the Server the file is copied to /var/lib/openshift/xxx/app-root/data/basex/repo/xqs/list_ba_flyer.xq
How can I run the Query-File via the REST-Interface?
Thanks for your advice and again for your great work!
Best, Günter
Am 31.03.2016 um 00:29 schrieb Andy Bunce bunce.andy@gmail.com:
Hi, A new version is available at https://github.com/Quodatum/openshift-basex-quick-start.
New features: • Enable REST and WebDAV • support for setting initial users • support for setting initial data • Use Java 8 Thanks to Michael Sperberg-McQueen and Günter Dunz-Wolff for helpful comments on the previous version.
/Andy