exist-db / node-exist Goto Github PK

The default repository URL is set to https://exist-db.org/exist/apps/public-repo.

db.app.install fails to install packages using default repository URL because of eXist-db/public-repo#74

As a workaround pass http://exist-db.org/exist/apps/public-repo as your custom repository URL.

Example

db.app.install(xarName, "http://exist-db.org/exist/apps/public-repo")

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

This will allow the npm package to ignore the spec folder and will result in a smaller package size.

• move ./spec/examples/* to ./bin
• change package.json to pick up CLI tools from new location
• add ./spec to npm ignore
• copy ./spec/connection.js to ./bin
• adapt ./bin/connection.js to meet CLI tool requirements (maybe default to guest/guest instead of admin)

Remove files in an existdb instance, mimicking the unix rm program.

Currently the raw bytes are listed, preferably this will behave as the unix ls command.

So that each value have a integer or floating point value of one to four characters in total followed by one character that determines if the numerical value is either

• bytes (B)
• kilobytes (K)
• megabytes (M)
• gigabytes (G)

Larger powers of 1024 (tera, peta, ...) are not considered at this point as resources that are this large are not feasible to be handled by exist at the moment.

I just noticed these on ci. Need to investigate further

Currently the extended listing of like exist-ls -l /db/apps does fail with Invalid option : timeStyle unless full-icu is installed globally.

https://github.com/yargs/yargs/blob/main/docs/advanced.md#testing-a-command-module

synchronise a source folder with a target collection

Currently, only http protocol is supported.
To enable db instances that are only available through https, a few changes have to be made.

Switch to xmlrpc.createSecureClient if https is needed.

It is yet not decided on how to trigger switching to https.

Idea:

const ex = require('@existdb/node-exist')

ex.connect({
    'secure': true
})

Describe the bug

Looks like username admin is hardcoded in the authentication error message.

exsol:~$ npx -p @existdb/node-exist exist-ls /db/apps
Wrong password for user [admin] 

Forgot to pass credentials... Specify admin password via EXISTDB_PASS env var:

exsol:~$ env | grep EXIST
EXISTDB_PASS=MY_ADMIN_SECRET
exsol:~$ npx -p @existdb/node-exist exist-ls /db/apps
Wrong password for user [admin] 

Probably the default guest user is used for login, but why does it report "wrong pass for user admin"? Explicitly setting EXISTDB_USER works as expected.

exsol:~$ env | grep EXIST
EXISTDB_USER=admin
EXISTDB_PASS=MY_ADMIN_SECRET
exsol:~$ npx -p @existdb/node-exist exist-ls /db/apps
[... works ...]

Expected behavior
Report wrong password for the username that is actually used for authentication:

Wrong password for user [guest] 

Context (please always complete the following information):

• @existdb/[email protected]
• node v16.15.1
• npm 8.11.0
• Debian 10

Sort by

• name
• size
• age

allow sorting to be inverted (ascending instead of descending)

Sorting by name was originally requested by @joewiz and he suggests to sort the listing in XQuery using the collation http://www.w3.org/2013/collation/UCA?numeric=yes.

Download resources or collection trees from an existdb into the filesystem.

• exist-get source-collection target-directory
• exist-get resource target

This Is more of a question:
Should node-exist read the settings file used by atom-existdb and existdb-langserver?

When exist-ls tries to read permissions on a collection the current user is not allowed to access it will throw an error and stop.

Steps to reproduce

run

EXISTDB_USER=guest \
EXISTDB_PASS=guest \
exist-ls --extended /db/system

The above will return

exerr:ERROR Permission to retrieve permissions is denied for user 'guest' on '/db/system/security': Permission denied to open collection: /db/system/security by guest

refs eXist-db/exist#4240

Similar to ls -d that only lists directories we could introduce flags that will limit output of exist-ls to either resources or collections.

A flag to see only XML or binary resources might also be useful.
Even the possibility to list only files of a specific mime-type could come in handy.

Feature originally requested by @chakl

why would it expect \n here or is that what's being tested.
We could prettify the response and remove the newlines from the expected results?

db/pkgtmp used for xar installs hangs around after use, which adds another location where outdated xars might unneccesarily accumulate.

since this is a temporary collection, node-exist should clean up after itself, without user intervention

user docker images for creating exist-db instanced and running test.
Let's see if these are faster or not

Possible names:

• exist-package
• exist-pkg
• expath-pkg

exist-pkg [options]

Should return tabulated list with package-abbreviation and version.

Example Output:

package-service  1.2.39
dashboard        10.3.2
monex             3.0.3
html-templating   1.0.4
eXide             3.0.1

Possible options:

• --libraries, -l or -L: list only installed libraries
• --applicationts, -a or -A: list only installed applications
• --filter, -f: list only libraries and/or applications that match a given pattern
• --extended, -e: add more information to the result (date of installation, namespace URI, declared dependencies, ...)
• --json, -j: return result as json (in order to pipe it to jq for example or store it in a file)

Please have a look at the successor xst
When that is released the CLI examples will only be available in the repository for documentation purposes - actual examples.

The newer ones (like exist-ls) already define and parse optStrings, or command line parameters, with yargs.

This should also be done for exist-install

exist-exec should execute queries in an existdb instance and the result should go to standard out

The query can be provided as a positional argument:

$ exist-exec '1 to 9'
1 2 3 4 5 6 7 8 9

The query can be in a file:

Contents of query.xq

1 to 9

$ exist-exec -f query.xq
1 2 3 4 5 6 7 8 9

I now have a pretty robust and dynamic test generator for xqsuite tests executed on the server and then "parsed" by Mocha. see generators/app/templates/tests/xqs/xqSuite.js. Should we include that here?

The only thing that we would need to adjust is adding a method to provide the location of the xqsuite runner (and or suite) file.

The downside it would add Mocha as a dependency.

The upside you could run xqsuite tests from inside node-exist.

@line-o what do you think?

existdb/existdb:release

Hi. With this code I can upload a XML file to the instance of ExistDB I'm connected to without any problem, if executed locally (not on the host the DB is in).

`

const path = collection.concat(data.recordId).concat('.xml'); 

const content = Buffer.from(modifiedXML); 

const fh = await db.documents.upload(content, content.length);

const r = await db.documents.parseLocal(fh, path);

`

However, I'm unable to upload anything when the script is executed from inside a Docker container, as it timeouts during the upload function. From the container I can even correctly ping the IP address of my ExistDB instance. The DB is on a container on the same host

Is it possible to upload from a container? Do I need some more configurations?

Thanks in advance