[Eliot, apologies for the duplicate mail -- I just realized that my
initial replies weren't CC'd to the list. Note that this fixes a bug
in the last version I sent you privately; please use it in
preference].
---
Please see BashFAQ #50: http://mywiki.wooledge.org/BashFAQ/050;
argument lists
Howdy --
I've run into a somewhat confusing error message using GROUP BY in BaseX
7.8.1, while trying to answer a question on StackOverflow (
http://stackoverflow.com/questions/22585865/grouping-with-counts-in-xquery).
Against the database at
Howdy --
Something I'd like to see would be the ability to make assertions about
which databases a query will need a write lock on, such that the queries
will fail at runtime if such an assertion was made but more locks are
needed than were declared.
This could allow more fine-grained locking to
BaseX is implemented in Java, so it runs on any platform with a JVM
available. No native compilation is necessary.
On Tue, Nov 12, 2013 at 8:44 AM, yoann ponzo y.po...@aliant.fr wrote:
I wanted to know if BaseX works under Unix OS like FreeBSD:
- http://www.freebsd.org/
Thank you.
It's not necessarily true that immutable data structures perform an actual
in-memory copy. See for instance Phil Bagwell's hash tries -- only minimal
amounts of the data structure are actually copied during updates.
I don't know whether BaseX is making use of these optimizations (Christian
could
On Tue, Nov 12, 2013 at 3:05 PM, jean-marc Mercier
jeanmarc.merc...@gmail.com wrote:
Thus I could use maps to simulate HashSet, it not a very big overload.
However, is there any incentive to trade off 20% performance ?
Immutability is its own reward, or, rather, comes with its own set of
Howdy, all --
If I run the following query against a large, full-text-indexed store
(output from svn log --xml on a repository with several hundred thousand
entries), I get results back in well under a second:
count(/log/logentry[./paths/path/text() contains text trunk])
However, the following
Howdy --
I'm trying to determine whether sql:execute-prepared exists, to have a
module that functions in both BaseX 7.3 and 7.5.
However --
exists(function-lookup(xs:QName(sql:execute-prepared), 2))
returns false even in BaseX 7.5, even though
Howdy --
I have the following code, which worked perfectly with BaseX 7.3:
declare function sqlimport:load-sql-source-raw($config as element(config),
$sql_source as element(sql-source)) {
let $handle := sql:connect(
concat($sql_source/@uri, /,
Howdy --
For the most part, I'm glad to have the non-EXPath packaging mechanism
introduced for 7.2.1 -- particularly given how the EXPath implementation
in BaseX has some unintended side effects (ie. loading all modules when
only one is referenced).
However, I wonder if perhaps the current
On 04/03/2012 03:43 PM, Christian Grün wrote:
I've frequently noticed when switching between trees that admin account
switches back to its default password, and my more limited user accounts
disappear and need to be recreated.
Global users are stored in the .basexperm file, while local
On 04/02/2012 08:07 AM, Christian Grün wrote:
Work started on that, present in my github tree
(https://github.com/charles-dyfis-net/basex/commits/java_util_logging).
Good news, I'll look at that soon.
FYI -- I rather strongly disagree with building our own indirection layer to
dynamically
On 04/02/2012 08:07 AM, Christian Grün wrote:
Work started on that, present in my github tree
(https://github.com/charles-dyfis-net/basex/commits/java_util_logging).
Good news, I'll look at that soon.
FYI --
I just checked in today's work (which includes better support for
controlling
Howdy --
Right now, logging in BaseX is managed through org.basex.server.Log,
allocated within each BaseXServer instance and passed to classes such as
ClientListener with a known need to do logging.
Compared to common logging approaches, this is somewhat unfortunate --
any class not passed
On 04/01/2012 04:26 PM, Christian Grün wrote:
Hi Charles,
Is the decision to use an in-house logging framework open to
reconsideration? I'd be willing to do a first-draft cut on a transition to
log4j, Sun's java.util.logging, or Apache Commons Logging (a thin
indirection layer which can use
On 04/01/2012 05:24 PM, Christian Grün wrote:
Could you quickly run through the requirements for a logging system in
BaseX, to be sure we're on the same page?
Just a short one... It might be a good start to check out the existing
debug mode, which is very cheap, too, and rewrite it in a way
2012/3/30 Christian Grün christian.gr...@gmail.com
Hi,
My first idea would be to try and lock the main table of the database,
`tbl.basex`, via FileChannel.tryLock(). That should be just as effective
in
preventing concurrent access, with the added benefit of leaving no
orphaned
files
Howdy --
Using the REST interface, I'm currently able to do the following:
rest:query xmlns:rest=http://basex.org/rest;
rest:text$foo/rest:text
rest:variable name=foo value=bar/
/rest:query
...and get back bar as a result. Note the lack of a declare variable
$foo external line.
I
Howdy --
Is any mechanism available for queries to log errors out-of-band without
modifying their return values?
Something like a wrapper around log4j would be perfect; right now I'm
using file:append(), but as this requires my queries to know where the
system administrator wants things to
Howdy --
I recently had an update run via the REST interface fail due to the
database being opened by another client. This would be unsurprising
were it taking place on a workstation where a concurrent process such as
basexgui might have been running, but the host in question was a server,
On 03/28/2012 01:49 PM, Ronny Möbius wrote:
I'm now interested in your general opinion about this: Is it surprising,
that the XQuery implementation than the lxml/python one (For me it is,
as I thought the indices etc. created when importing the data should
decrease computational affords in
Howdy --
For JSON and XML, mechanisms to generate an in-memory document from an
xs:string() exist. For CSV or text inputs, however, I'm unclear on how
to do this without declaring options and invoking db:add() -- not ideal
when the content being handled is intended only for transient,
Howdy --
Right now, trying to inspect a map (ie. returning one from a query)
results in FOTY0012. This is unfortunate from the perspective of
allowing users to examine the objects their logic creates. Has thought
been given to defining a serialization-friendly way of representing
maps,
Quick question --
Does the ADMIN restriction apply to classes extending QueryModule as
well as those found via reflection?
I didn't see the permissions checks when poking around the relevant
code, and am thus not quite sure where they are -- but to me, it would
make sense to have
Howdy --
I'm trying to include (and use) a jar in a package, and not having any
luck of it just yet. Could I get any guidance on what I might be missing
here?
=== BEGIN expath-pkg.xml
package
xmlns=http://expath.org/ns/pkg;
spec=1.0
Howdy --
Historically, the BaseX REST API has handled exceptions by returning
only the exception content itself.
I just ran a build against current SVN, and received the following:
html
head
meta http-equiv=Content-Type content=text/html; charset=ISO-8859-1/
titleError 400 Stopped at line 1,
On 03/21/2012 02:24 PM, Charles Duffy wrote:
Found one issue (using strace -f -e trace=file basexhttp):
BaseX was attempting to look for the file at
$PACKAGE/svnkit/svnkit-wrapper.jar
...whereas I placed it at
$PACKAGE/svnkit-wrapper.jar
However, with this resolved, strace shows that BaseX
On 03/18/2012 06:59 PM, Christian Grün wrote:
Currently, there is no mechanism yet to detect orphaned pin files, as
the first tests I did with channel().lock() etc. haven't been that
successful, or too slow.
Hmm.
According to the docs, java.nio.channels.FileLock should be implemented
on
Howdy --
The ability to call arbitrary Java code from XQuery being accessible
only to users with ADMIN privileges is generally sensible for obvious
reasons.
However, it would be useful for users with ADMIN privileges to be able
to install packages in such a way as to make classes contained
On 3/18/2012 6:09 AM, Dimitar Popov wrote:
Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell:
Note also that there are a few different aspects of this that people may be
confusing/conflating...
* Protecting the user credentials for long-term storage in the database itself.
*
So -- I might implement this eventually, as a spare-time thing. The
first thing that concerns me -- something strong, like bcrypt, will make
the REST interface, with its per-command authentication (lack of
sessions) unworkably expensive, so there should be some forethought into
how we'd want
On 03/16/2012 03:34 PM, Christian Grün wrote:
The context() method has been added. Moreover, I have added new bind()
and context() function signatures to the client APIs with an
additional type argument.
Most excellent; thanks!
I'm a little curious how the default behavior when no type value
On 03/17/2012 04:47 PM, Christian Grün wrote:
[...] The first
thing that concerns me -- something strong, like bcrypt, will make the REST
interface, with its per-command authentication (lack of sessions) unworkably
expensive [...]
I agree, performance is very essential here. What about using
Howdy --
I have a BaseX database with a pin-* file in its directory, reporting as
locked and unavailable. However, OS-level tools such as fuser report
that no programs have open file handles for any processes in this directory.
What mechanism does BaseX use for detecting abandoned locks? It
2012, 15:58:55 schrieb Charles Duffy:
Dimitar,
Using SSL gives you transport-layer security, but is no help at all for
authentication, unless you're using client certificates (in which case
there still _is_ per-session state, but it's hidden behind the SSL sessions
maintained on both client
On 03/14/2012 07:44 PM, Charles Duffy wrote:
Howdy --
Right now, I'm aware of two ways to set the context item via the native
protocol:
(1) Insert a declare context item header into the document
- Disadvantage: Should only work when XQUERY3 is true
- Disadvantage: Modifies line/column
On 03/16/2012 11:06 AM, Charles Duffy wrote:
On 03/14/2012 07:44 PM, Charles Duffy wrote:
Howdy --
Right now, I'm aware of two ways to set the context item via the native
protocol:
(1) Insert a declare context item header into the document
- Disadvantage: Should only work when XQUERY3
In my .basex file:
REPOPATH = /home/cduffy/local/opt/basex-data/repo
...and running repo:list() shows my local package, with namespace
http://dyfis.net/ as installed, but trying to use anything from it leads
to an error similar to the following:
releng.db.basex.rest.RemoteException:
...@dyfis.net wrote:
On 03/16/2012 01:13 PM, Charles Duffy wrote:
In my .basex file:
REPOPATH = /home/cduffy/local/opt/basex-data/repo
...and running repo:list() shows my local package, with namespace
http://dyfis.net/ as installed, but trying to use anything from it leads
to an error similar
Howdy --
I'm a bit concerned about storing password hashes unsalted -- compared
to a salted hash, this makes a stolen database easier to retrieve user
passwords from, dangerous if users use their passwords for other
purposes as well.
Would salting (and perhaps stretching) the hashes be
On 03/14/2012 08:39 PM, Charles Duffy wrote:
On 03/14/2012 08:08 PM, Christian Grün wrote:
-- If you are working more low level, you can directly bind items to
the QueryProcessor [1]
...which would be perfect if my usage were embedded. That said, this is
actually very compelling -- if only I
Restated: ADD is to REPLACE as STORE is to... what?
REPLACE, like ADD, expects the content given to be parsed rather than
raw. ADDing the same content twice can result in two documents with the
same name in the database; I'm presuming that duplicate STORE commands
have similar peril attached.
REPLACE inventory root foo=bartest/root
Stopped at line 1, column 24:
Syntax: REPLACE [path] [input]
Replace documents in database.
Replaces documents in the current database.
___
BaseX-Talk mailing list
BaseX-Talk@mailman.uni-konstanz.de
On 03/15/2012 03:48 PM, Charles Duffy wrote:
REPLACE inventory root foo=bartest/root
Stopped at line 1, column 24:
Syntax: REPLACE [path] [input]
Replace documents in database.
Replaces documents in the current database.
Filed a bug at https://github.com/BaseXdb/basex/issues/437
Oops -- I built my own snapshot (after the 20120313.033119 snapshot
didn't demonstrate the desired behavior), but failed to change the
symlink, so it wasn't actually running. My apologies for the noise; this
functionality *does* now work.
On 03/13/2012 06:11 PM, Christian Grün wrote:
The
Howdy --
Right now, I'm aware of two ways to set the context item via the native
protocol:
(1) Insert a declare context item header into the document
- Disadvantage: Should only work when XQUERY3 is true
- Disadvantage: Modifies line/column references for errors received
- Disadvantage: Hard
On 3/8/2012 8:58 PM, jida...@jidanni.org wrote:
On http://docs.basex.org/wiki/Serialization we see
newline.
But we have no idea how to make it work.
Please add an example to that page!
declare option output:method text;
declare option output:newline \n;
for $m in (1,2,3)
return $m
Nope
This is something I'm quite interested in seeing resolved -- if you
could provide some guidance (either here or via discussion attached to
the github issue) on what an proper fix would look like, I'd be happy to
try my hand at a patch if that would help get it into the next point
release.
Howdy --
As best I can tell, there are currently two ways to list installed
packages:
- The REPO LIST command, which returns complete output, but in a format
clearly intended for human consumption.
- The repo:list() function, which is more programatically accessible but
returns only
49 matches
Mail list logo
