I think I have the issue worked out. The whole thing is based off of the contents of a git repo. Some metadata is collected and stored in the database. If I setup the server to sync the repos and add the resources rather than managing that process locally, this problem disappears. That of course is how it will work in production but for testing it's helpful to manage things locally. It would be helpful to understand why simply deploying the built database would seemingly corrupt specific resources. I can understand if it ended up corrupting the entire database but the fact that it was only impacting select resources is confusing.
To answer your questions:
1. Do you start the web server with `basexhttp` both on the local and the remote machine? [JD] Yes 2. Are both machines based on the same operating system (presumably Linux)? [JD] Locally: Mac OS X Mojave 10.14.6, server: CentOS 7 3. Are there any other differences between the two systems? [JD] Generally, no. Both are running Tomcat although locally Tomcat 8 vs. Tomcat 9 on the server 4. If you log into the remote machine: Do you experience the same obstacles when calling http://localhost:8984... on that machine? [JD] Yes but I think my observations above explain that 5. Does it make a difference if you replace %5E with ^ in the URL? [JD] No
Thanks for your time! Jason
On Fri, Mar 13, 2020 at 3:53 AM Christian Grün christian.gruen@gmail.com wrote:
Interesting indeed. So I’ll just keep on asking:
- Do you start the web server with `basexhttp` both on the local and
the remote machine? 2. Are both machines based on the same operating system (presumably Linux)? 3. Are there any other differences between the two systems? 4. If you log into the remote machine: Do you experience the same obstacles when calling http://localhost:8984... on that machine? 5. Does it make a difference if you replace %5E with ^ in the URL?
On Thu, Mar 12, 2020 at 8:29 PM Jason Davis jason.davis@cloudera.com wrote:
So,I ran a few tests. I started by just adding the doc in question.
open d4st^newco-docs^master add /path/to/document/KuduVariables.xml
list d4st^newco-docs^master
Input Path Type Content-Type Size
.d4st/metadata.xml xml application/xml 11 KuduVariables.xml xml application/xml 65
2 Resource(s).
As expected, I'm able to successfully access it locally, both through a
simple web interface I have setup and the CLI.
web acces: user REQUEST [GET]
http://localhost:8984/linkmgr/docview//d4st%5Enewco-docs%5Emaster/KuduVariab...
user 200 143.88 ms
CLI:
delete KuduVariables.xml
1 resource(s) deleted in 0.76 ms.
list d4st^newco-docs^master
Input Path Type Content-Type Size
.d4st/metadata.xml xml application/xml 11
1 Resource(s).
When I deploy this to the server without making any changes, the
resource becomes inaccessible.
web access: admin REQUEST [GET]
http://X.X.X.X:8984/linkmgr/docview//d4st%5Enewco-docs%5Emaster/KuduVariable...
admin 400 Stopped at /opt/basex/webapp/linkmgrViews.xqm, 90/19:
[basex:doc] Database path 'd4st^newco-docs^master/KuduVariables.xml' yields no documents. 350.65 ms
CLI:
list d4st^newco-docs^master
Input Path Type Content-Type Size
.d4st/metadata.xml xml application/xml 11 KuduVariables.xml xml application/xml 65
2 Resource(s).
delete KuduVariables.xml
0 resource(s) deleted in 0.86 ms.
It literally is affecting just this one document. I've tested it by
adding a couple other random docs and there are no problems accessing those. There is no difference in file permissions between all the docs getting added to the db. I am stumped!
Jason
On Thu, Mar 12, 2020 at 1:02 AM Christian Grün <
christian.gruen@gmail.com> wrote:
Hi Jason,
difficult to tell out of the box what might go wrong here. Could you provide us with some minimized lines of code that tell how you access and delete the document in question? Does the problem also occur if you create a new database with a single document?
I have attached a little test script which you could adapt and evaluate locally via REST [1].
Best, Christian
[1] http://docs.basex.org/wiki/REST
On Thu, Mar 12, 2020 at 7:23 AM Jason Davis jason.davis@cloudera.com
wrote:
Hello, I have a confounding problem involving a database that is deployed to
a web server. The database will support a web app that provides an SPA interface to the database and lists resources through various APIs. When I test the app locally, everything works fine.
However, when I deploy the database to a web server, one file in
particular grounds the app to a halt. Apparently, this particular document does not exist in the database:
[basex:doc] Database path
'd4st^newco-docs^master/shared/KuduVariables.xml' yields no documents.
In addition, I can use the CLI to list the database contents and it's
clearly listed there. When I attempt to delete it (i.e. delete shared/KuduVariables.xml), the result is 0 resources deleted. What would cause something like this to happen? Is there a preferred method for deploying the db that would prevent weird things like this happening?
Thanks, Jason
-- Jason Davis Staff Tools Engineer, Content Development jason.davis@cloudera.com Mobile: 510-225-8281
-- Jason Davis Staff Tools Engineer, Content Development jason.davis@cloudera.com Mobile: 510-225-8281