Hi all,
I wanted to post back with an attempt at fixing this, but I'm afraid I
don't have anything successful to report. I forked ligasgr's repository [1]
and tried to make what seemed to be the necessary changes to update things
but I run into problems when I try to run some of the gradle command
Hi Ketill,
Welcome to our list.
XQJ was written to be compliant with XQuery 1.0, so it may well be
that the db:output extension cannot be used with our (well, Charles
Foster's) implementation of XQJ (yet). Have you tried to set the
MIXUPDATES flag to true instead?
All the best,
Christian
On We
Hi!
I am executing all Xqueries through the same runQuery method in Java, and I
am running the latest jar-files (8.0.1):
XQDataSource ds = new BaseXXQDataSource();
xqc = ds.getConnection();
XQExpression xqe = xqc.createExpression();
rs = xqe.execute
I’m trying an exemple below, but after a closer look, everything is alright. I
was confused by QNames construction…
If we had two different modules.
In the first one
module namespace x = ‘x' ;
declare default function namespace 'x';
declare function a() { 1};
declare function x:b() { 1};
decla
> Thus if I understood correclty:
> What you propose here is to not have the UPDINDEX=true but rather re-run an
> "create index *; optimize (all)"
If you have already checked performance, it's completely fine to use UPDINDEX.
On 25/02/2015 14:51, Christian Grün wrote:
A cold one which is growing (with scheduled batch ops) but indexed and
UPDINDEX=true (for rare update operations that still might occur) and a hot
one for realtime data which has no index but whose size will be reduced and
kept constant.
This makes perf
> A cold one which is growing (with scheduled batch ops) but indexed and
> UPDINDEX=true (for rare update operations that still might occur) and a hot
> one for realtime data which has no index but whose size will be reduced and
> kept constant.
This makes perfect sense. You could also think about
Hello,
I am a happy BaseX user.
Currently I am trying to help other teams to find right solution to their data
mining from huge xml data store. They are going after postgre and probably even
db2. Nor that I have any influence over their decision, but I would like to
alert them about something
Hello all,
putting the PARALLEL flag to 1 solved the issue of inconsistency between
the query + scheduling time and the actual operation completion time.
Now we have it stabilized.
Thanks.
Peaks are now rarely possible when an update from the insertion client
serializes itself with one or more
Hi!
Just a reminder to update the homebrew distribution as well!
Regards,
Johan Mörén
On Sun, Feb 22, 2015 at 10:07 PM Christian Grün
wrote:
> Hi there,
>
> We have just released a first post-Prague version of BaseX, which
> includes some minor optimizations and fixes (nothing critical):
>
> X
10 matches
Mail list logo
