Re: [basex-talk] rest vs. restxq - strange difference
As an update, after rebuilding database with
text index,
full text index (no language, no stemming, keep diacritics)
restarting server:
BaseX 8.1.1 [Server]
Server was started (port: 29084)
[main] INFO org.eclipse.jetty.server.AbstractConnector - Started
SelectChannelConnector@0.0.0.0:8984
HTTP Server was started (port: 8984)
RESTXQ: Norwegian characters are converted using full text index, changing
to text index takes forever.
REST: Full-text works as expected, and text index works as expected (same
as runing in GUI for both).
It looks as if the index structure is treated differently.
2015-05-18 15:07 GMT+02:00 Lars Johnsen yoon...@gmail.com:
The full text query is blisteringly fast for both, the text index query is
fast only for REST queries and seems not to be used with queries in RESTXQ.
I am rebuilding the whole database now to see how it goes, and will restart
everything for a new assessment.
2015-05-18 15:00 GMT+02:00 Christian Grün christian.gr...@gmail.com:
However, when using text index instead of full text the results are the
same
for both, except that RESTXQ takes almost forever
What about the original query: Has it been slow as well, or do you
think this is a new problem?
2015-05-18 14:28 GMT+02:00 Christian Grün christian.gr...@gmail.com:
It could be that your URL is decoded in a wrong way.. What happens if
you run the following function with REST and RESTXQ and føre as
word?
declare
%rest:path(/test/encoding/{$word})
function page:test-encoding($word) {
string-to-codepoints($word)
};
Thanks,
Christian
string-to-codepoints()
REST output (2 first lines):
føre
fø - re 219
RESTXQ
føre
fo - re 123
The first word quoted is føre in both cases and is what the scripts
see,
so the full text is given the same in both cases. Could it be that
within
RESTXQ the full text index is treated differently?
I will work closer on a self contained example, but thought this
might
point to something.
Cheers
Lars
2015-05-18 13:44 GMT+02:00 Lars Johnsen yoon...@gmail.com:
Hi Christian - and thanks for fast response. Latest version 8.11 is
in
use
(same behaviour as previous). Let me see if I can make a self
contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün
christian.gr...@gmail.com:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you think
you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com
wrote:
I am running a web script in two identical versions (identical
as in
cut
and paste), one via RESTXQ and one vi REST. The response is
different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only the
REST
version shows any result, which then is the same as I get
experimenting
in
the GUI.
The actual script is added below, and which runs in both versions
(identical apart form the rest and restxq interfaces), it uses
full
text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full
contains
text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total := sum($hyphens//@freq)
let $div := element div {
element p {$word},
for $hyp in $hyphens
return element div {
attribute class {hyph},
attribute style {font-size:, 1
+round(xs:int($hyp//@freq/data())
div $total,1) || em},
$hyp
}
}
return
html encoding=UTF-8
head
meta http-equiv=Content-Type content=text/html
charset=UTF-8
/
titleOrddelinger/title
/head
body{$div}
/body
Re: [basex-talk] rest vs. restxq - strange difference
However, when using text index instead of full text the results are the same
for both, except that RESTXQ takes almost forever
What about the original query: Has it been slow as well, or do you
think this is a new problem?
2015-05-18 14:28 GMT+02:00 Christian Grün christian.gr...@gmail.com:
It could be that your URL is decoded in a wrong way.. What happens if
you run the following function with REST and RESTXQ and føre as
word?
declare
%rest:path(/test/encoding/{$word})
function page:test-encoding($word) {
string-to-codepoints($word)
};
Thanks,
Christian
string-to-codepoints()
REST output (2 first lines):
føre
fø - re 219
RESTXQ
føre
fo - re 123
The first word quoted is føre in both cases and is what the scripts
see,
so the full text is given the same in both cases. Could it be that
within
RESTXQ the full text index is treated differently?
I will work closer on a self contained example, but thought this might
point to something.
Cheers
Lars
2015-05-18 13:44 GMT+02:00 Lars Johnsen yoon...@gmail.com:
Hi Christian - and thanks for fast response. Latest version 8.11 is in
use
(same behaviour as previous). Let me see if I can make a self contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün christian.gr...@gmail.com:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you think you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com
wrote:
I am running a web script in two identical versions (identical as in
cut
and paste), one via RESTXQ and one vi REST. The response is
different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only the
REST
version shows any result, which then is the same as I get
experimenting
in
the GUI.
The actual script is added below, and which runs in both versions
(identical apart form the rest and restxq interfaces), it uses full
text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full contains
text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total := sum($hyphens//@freq)
let $div := element div {
element p {$word},
for $hyp in $hyphens
return element div {
attribute class {hyph},
attribute style {font-size:, 1
+round(xs:int($hyp//@freq/data())
div $total,1) || em},
$hyp
}
}
return
html encoding=UTF-8
head
meta http-equiv=Content-Type content=text/html
charset=UTF-8
/
titleOrddelinger/title
/head
body{$div}
/body
/html
};
Re: [basex-talk] rest vs. restxq - strange difference
The full text query is blisteringly fast for both, the text index query is
fast only for REST queries and seems not to be used with queries in RESTXQ.
I am rebuilding the whole database now to see how it goes, and will restart
everything for a new assessment.
2015-05-18 15:00 GMT+02:00 Christian Grün christian.gr...@gmail.com:
However, when using text index instead of full text the results are the
same
for both, except that RESTXQ takes almost forever
What about the original query: Has it been slow as well, or do you
think this is a new problem?
2015-05-18 14:28 GMT+02:00 Christian Grün christian.gr...@gmail.com:
It could be that your URL is decoded in a wrong way.. What happens if
you run the following function with REST and RESTXQ and føre as
word?
declare
%rest:path(/test/encoding/{$word})
function page:test-encoding($word) {
string-to-codepoints($word)
};
Thanks,
Christian
string-to-codepoints()
REST output (2 first lines):
føre
fø - re 219
RESTXQ
føre
fo - re 123
The first word quoted is føre in both cases and is what the scripts
see,
so the full text is given the same in both cases. Could it be that
within
RESTXQ the full text index is treated differently?
I will work closer on a self contained example, but thought this
might
point to something.
Cheers
Lars
2015-05-18 13:44 GMT+02:00 Lars Johnsen yoon...@gmail.com:
Hi Christian - and thanks for fast response. Latest version 8.11 is
in
use
(same behaviour as previous). Let me see if I can make a self
contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün christian.gr...@gmail.com
:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you think
you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com
wrote:
I am running a web script in two identical versions (identical as
in
cut
and paste), one via RESTXQ and one vi REST. The response is
different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only the
REST
version shows any result, which then is the same as I get
experimenting
in
the GUI.
The actual script is added below, and which runs in both versions
(identical apart form the rest and restxq interfaces), it uses
full
text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full
contains
text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total := sum($hyphens//@freq)
let $div := element div {
element p {$word},
for $hyp in $hyphens
return element div {
attribute class {hyph},
attribute style {font-size:, 1
+round(xs:int($hyp//@freq/data())
div $total,1) || em},
$hyp
}
}
return
html encoding=UTF-8
head
meta http-equiv=Content-Type content=text/html
charset=UTF-8
/
titleOrddelinger/title
/head
body{$div}
/body
/html
};
Re: [basex-talk] rest vs. restxq - strange difference
It could be that your URL is decoded in a wrong way.. What happens if
you run the following function with REST and RESTXQ and føre as
word?
declare
%rest:path(/test/encoding/{$word})
function page:test-encoding($word) {
string-to-codepoints($word)
};
Thanks,
Christian
string-to-codepoints()
REST output (2 first lines):
føre
fø - re 219
RESTXQ
føre
fo - re 123
The first word quoted is føre in both cases and is what the scripts see,
so the full text is given the same in both cases. Could it be that within
RESTXQ the full text index is treated differently?
I will work closer on a self contained example, but thought this might
point to something.
Cheers
Lars
2015-05-18 13:44 GMT+02:00 Lars Johnsen yoon...@gmail.com:
Hi Christian - and thanks for fast response. Latest version 8.11 is in use
(same behaviour as previous). Let me see if I can make a self contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün christian.gr...@gmail.com:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you think you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com wrote:
I am running a web script in two identical versions (identical as in
cut
and paste), one via RESTXQ and one vi REST. The response is different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only the REST
version shows any result, which then is the same as I get experimenting
in
the GUI.
The actual script is added below, and which runs in both versions
(identical apart form the rest and restxq interfaces), it uses full
text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full contains
text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total := sum($hyphens//@freq)
let $div := element div {
element p {$word},
for $hyp in $hyphens
return element div {
attribute class {hyph},
attribute style {font-size:, 1
+round(xs:int($hyp//@freq/data())
div $total,1) || em},
$hyp
}
}
return
html encoding=UTF-8
head
meta http-equiv=Content-Type content=text/html
charset=UTF-8
/
titleOrddelinger/title
/head
body{$div}
/body
/html
};
Re: [basex-talk] rest vs. restxq - strange difference
Tried to make a small example but then things worked the same, so reindexed
the database (no language and no stemming) and found this. It seems that it
has to to with character encoding.
RESTXQ finds hits for føre as fore while REST treats it as føre so
the outputs are like this
REST output (2 first lines):
føre
fø - re 219
RESTXQ
føre
fo - re 123
The first word quoted is føre in both cases and is what the scripts see,
so the full text is given the same in both cases. Could it be that within
RESTXQ the full text index is treated differently?
I will work closer on a self contained example, but thought this might
point to something.
Cheers
Lars
2015-05-18 13:44 GMT+02:00 Lars Johnsen yoon...@gmail.com:
Hi Christian - and thanks for fast response. Latest version 8.11 is in use
(same behaviour as previous). Let me see if I can make a self contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün christian.gr...@gmail.com:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you think you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com wrote:
I am running a web script in two identical versions (identical as in
cut
and paste), one via RESTXQ and one vi REST. The response is different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only the REST
version shows any result, which then is the same as I get experimenting
in
the GUI.
The actual script is added below, and which runs in both versions
(identical apart form the rest and restxq interfaces), it uses full text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full contains text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total := sum($hyphens//@freq)
let $div := element div {
element p {$word},
for $hyp in $hyphens
return element div {
attribute class {hyph},
attribute style {font-size:, 1
+round(xs:int($hyp//@freq/data())
div $total,1) || em},
$hyp
}
}
return
html encoding=UTF-8
head
meta http-equiv=Content-Type content=text/html
charset=UTF-8
/
titleOrddelinger/title
/head
body{$div}
/body
/html
};
Re: [basex-talk] rest vs. restxq - strange difference
The codepoints are identical for both for føre:
102 248 114 101
and same as GUI.
However, when using text index instead of full text the results are the
same for both, except that RESTXQ takes almost forever (as if there was no
text index), while REST gives immediate result. So it looks as if the
RESTXQ accesses the index structure in a different way - could that be so,
or is there some strange things in my own configuration?
2015-05-18 14:28 GMT+02:00 Christian Grün christian.gr...@gmail.com:
It could be that your URL is decoded in a wrong way.. What happens if
you run the following function with REST and RESTXQ and føre as
word?
declare
%rest:path(/test/encoding/{$word})
function page:test-encoding($word) {
string-to-codepoints($word)
};
Thanks,
Christian
string-to-codepoints()
REST output (2 first lines):
føre
fø - re 219
RESTXQ
føre
fo - re 123
The first word quoted is føre in both cases and is what the scripts
see,
so the full text is given the same in both cases. Could it be that within
RESTXQ the full text index is treated differently?
I will work closer on a self contained example, but thought this might
point to something.
Cheers
Lars
2015-05-18 13:44 GMT+02:00 Lars Johnsen yoon...@gmail.com:
Hi Christian - and thanks for fast response. Latest version 8.11 is in
use
(same behaviour as previous). Let me see if I can make a self contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün christian.gr...@gmail.com:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you think you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com
wrote:
I am running a web script in two identical versions (identical as in
cut
and paste), one via RESTXQ and one vi REST. The response is
different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only the
REST
version shows any result, which then is the same as I get
experimenting
in
the GUI.
The actual script is added below, and which runs in both versions
(identical apart form the rest and restxq interfaces), it uses full
text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full contains
text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total := sum($hyphens//@freq)
let $div := element div {
element p {$word},
for $hyp in $hyphens
return element div {
attribute class {hyph},
attribute style {font-size:, 1
+round(xs:int($hyp//@freq/data())
div $total,1) || em},
$hyp
}
}
return
html encoding=UTF-8
head
meta http-equiv=Content-Type content=text/html
charset=UTF-8
/
titleOrddelinger/title
/head
body{$div}
/body
/html
};
Re: [basex-talk] Open database outside DBPATH
Hi Ketill, Maybe this has been answered before, but is it possible to open and read a database located outside DBPATH? Sorry, no. Currently, what you can do is.. * set DBPATH via system properties before starting BaseX [1], * create symbolic links in your database directory, or * copy your databases in the db directory.. But I'm not sure if any of these options meets your requirements? Christian [1] http://docs.basex.org/wiki/Options
Re: [basex-talk] Open database outside DBPATH
Ok, thanks! My requirement is that in a locally installed product that uses BaseX to store content I need to read a database(s) containing new/changed documents from (preferrably) an upgrade/ - folder and add/replace documents in the existing database(s) in the DBPATH - dir. I guess I'll move the database into DBPATH, install the updates, and then drop the database(s) containing the upgrades. Ketill Fenne On Mon, May 18, 2015 at 10:25 AM, Christian Grün christian.gr...@gmail.com wrote: Hi Ketill, Maybe this has been answered before, but is it possible to open and read a database located outside DBPATH? Sorry, no. Currently, what you can do is.. * set DBPATH via system properties before starting BaseX [1], * create symbolic links in your database directory, or * copy your databases in the db directory.. But I'm not sure if any of these options meets your requirements? Christian [1] http://docs.basex.org/wiki/Options
[basex-talk] Open database outside DBPATH
Hi! Maybe this has been answered before, but is it possible to open and read a database located outside DBPATH? Kind regards Ketill Fenne
Re: [basex-talk] Server protocol bug?
I missed the obvious part of option 'suboptions' I fixed the parsing in basex-stream and now `query.options()` returns an object in v0.1.2.
Re: [basex-talk] rest vs. restxq - strange difference
A last update, which may illuminate a little. After reindexing the database
using Norwegian (snowball), stemming, and keeping diacritis, RESTXQ
processes neither the special characters (treats them as closest ascii),
nor inflected forms.
The words mannen (=the man, definite) and spaserer (=walks, present
tense), result in no output, while using the naked stems mann and
spaser the full result is displayed. In contrast to REST which behaves as
expected.
Cheers
Lars
2015-05-18 15:28 GMT+02:00 Lars Johnsen yoon...@gmail.com:
As an update, after rebuilding database with
text index,
full text index (no language, no stemming, keep diacritics)
restarting server:
BaseX 8.1.1 [Server]
Server was started (port: 29084)
[main] INFO org.eclipse.jetty.server.AbstractConnector - Started
SelectChannelConnector@0.0.0.0:8984
HTTP Server was started (port: 8984)
RESTXQ: Norwegian characters are converted using full text index, changing
to text index takes forever.
REST: Full-text works as expected, and text index works as expected (same
as runing in GUI for both).
It looks as if the index structure is treated differently.
2015-05-18 15:07 GMT+02:00 Lars Johnsen yoon...@gmail.com:
The full text query is blisteringly fast for both, the text index query
is fast only for REST queries and seems not to be used with queries in
RESTXQ. I am rebuilding the whole database now to see how it goes, and will
restart everything for a new assessment.
2015-05-18 15:00 GMT+02:00 Christian Grün christian.gr...@gmail.com:
However, when using text index instead of full text the results are
the same
for both, except that RESTXQ takes almost forever
What about the original query: Has it been slow as well, or do you
think this is a new problem?
2015-05-18 14:28 GMT+02:00 Christian Grün christian.gr...@gmail.com:
It could be that your URL is decoded in a wrong way.. What happens if
you run the following function with REST and RESTXQ and føre as
word?
declare
%rest:path(/test/encoding/{$word})
function page:test-encoding($word) {
string-to-codepoints($word)
};
Thanks,
Christian
string-to-codepoints()
REST output (2 first lines):
føre
fø - re 219
RESTXQ
føre
fo - re 123
The first word quoted is føre in both cases and is what the
scripts
see,
so the full text is given the same in both cases. Could it be that
within
RESTXQ the full text index is treated differently?
I will work closer on a self contained example, but thought this
might
point to something.
Cheers
Lars
2015-05-18 13:44 GMT+02:00 Lars Johnsen yoon...@gmail.com:
Hi Christian - and thanks for fast response. Latest version 8.11
is in
use
(same behaviour as previous). Let me see if I can make a self
contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün
christian.gr...@gmail.com:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you
think you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com
wrote:
I am running a web script in two identical versions (identical
as in
cut
and paste), one via RESTXQ and one vi REST. The response is
different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only
the
REST
version shows any result, which then is the same as I get
experimenting
in
the GUI.
The actual script is added below, and which runs in both
versions
(identical apart form the rest and restxq interfaces), it uses
full
text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full
contains
text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total :=
Re: [basex-talk] Open database outside DBPATH
Hi! The only reason is that we are currently moving the product from using Oracle Berkeley XMLDB to BaseX, and would like to leave as much of the existing java-code as is :-) Ketill On Mon, May 18, 2015 at 10:51 AM, Dirk Kirsten d...@basex.org wrote: Hi Ketill, I don't fully understand your requirement. Why don't you simply add/replace the documents (using the database commands or within XQuery db:add(...) or db:replace(...)). This, of course, reads files from the file system to add them to the database. It looks much more suitable for the use case you describe, but maybe I am missing something. Cheers Dirk On Mon, May 18, 2015 at 10:35 AM, Ketill Fenne ketill.fe...@gmail.com wrote: Ok, thanks! My requirement is that in a locally installed product that uses BaseX to store content I need to read a database(s) containing new/changed documents from (preferrably) an upgrade/ - folder and add/replace documents in the existing database(s) in the DBPATH - dir. I guess I'll move the database into DBPATH, install the updates, and then drop the database(s) containing the upgrades. Ketill Fenne On Mon, May 18, 2015 at 10:25 AM, Christian Grün christian.gr...@gmail.com wrote: Hi Ketill, Maybe this has been answered before, but is it possible to open and read a database located outside DBPATH? Sorry, no. Currently, what you can do is.. * set DBPATH via system properties before starting BaseX [1], * create symbolic links in your database directory, or * copy your databases in the db directory.. But I'm not sure if any of these options meets your requirements? Christian [1] http://docs.basex.org/wiki/Options -- Dirk Kirsten, BaseX GmbH, http://basex.org |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
Re: [basex-talk] Open database outside DBPATH
Hi Ketill, I don't fully understand your requirement. Why don't you simply add/replace the documents (using the database commands or within XQuery db:add(...) or db:replace(...)). This, of course, reads files from the file system to add them to the database. It looks much more suitable for the use case you describe, but maybe I am missing something. Cheers Dirk On Mon, May 18, 2015 at 10:35 AM, Ketill Fenne ketill.fe...@gmail.com wrote: Ok, thanks! My requirement is that in a locally installed product that uses BaseX to store content I need to read a database(s) containing new/changed documents from (preferrably) an upgrade/ - folder and add/replace documents in the existing database(s) in the DBPATH - dir. I guess I'll move the database into DBPATH, install the updates, and then drop the database(s) containing the upgrades. Ketill Fenne On Mon, May 18, 2015 at 10:25 AM, Christian Grün christian.gr...@gmail.com wrote: Hi Ketill, Maybe this has been answered before, but is it possible to open and read a database located outside DBPATH? Sorry, no. Currently, what you can do is.. * set DBPATH via system properties before starting BaseX [1], * create symbolic links in your database directory, or * copy your databases in the db directory.. But I'm not sure if any of these options meets your requirements? Christian [1] http://docs.basex.org/wiki/Options -- Dirk Kirsten, BaseX GmbH, http://basex.org |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
Re: [basex-talk] Bug in declare base-uri
Hello Hans-Jürgen,
It has been a while, but the erroneous behavior of the base-uri
declaration should now be history (if it doesn't sound too pathetic).
A new snapshot will be available later today..
Regarding the declaration of invalid paths (e.g. with multiple parent
references), my impression so far is that every XQuery implementation
does something different, and I am not sure if/where it is
well-defined in the specs. For now, I'll simply assume that those
cases are (as Michael Kay likes to put it) pathological, and I have
closed the corresponding issue in our bug tracker [1].
Christian
[1] https://github.com/BaseXdb/basex/issues/1062
On Sat, Jan 24, 2015 at 9:02 AM, Christian Grün
christian.gr...@gmail.com wrote:
Hans-Jürgen,
Thanks for the report; I can confirm that the trailing slash is
missing in the result. I noticed it's quite a hassle to implement all
the XQuery URI resolutions in Java, because Java's default classes do
not comply 100% with RFC 3986.
I have added a new GitHub issue [1].
As you seem to have spent some time with the spec, can you possibly
tell me how the following URIs should correctly be resolved? I tried
some XQuery implementations, they all gave me different results...
declare base-uri ../../../../../../../../../../../..;
static-base-uri()
declare base-uri C:/;
static-base-uri()
declare base-uri C:/..;
static-base-uri()
Thanks in advance,
Christian
[1] https://github.com/BaseXdb/basex/issues/1062
On Fri, Jan 23, 2015 at 11:09 PM, Hans-Juergen Rennau hren...@yahoo.de
wrote:
Dear BaseX team,
I think there is a bug in the determination of the static base URI in the
special case that a base URI declaration contains a relative URI equal to or
starting with ...
Consider this declaration:
declare base-uri ..;
The effect should be that relative URIs are resolved against the PARENT
directory of the directory containing the query.
If the query is located at, say, file:///a/b/c/query.xq, I would expect the
static base-uri to be /a/b/, so that a URI like abc.xml would be resolved
to file:///a/b/abc.xml.
However, the static base URI as determined by BaseX in this case misses the
trailing /, it is: file:///a/b
The effect is that a URI like abc.xml would be resolved to
file:///a/abc.xml
In other words: URIs are resolved against the GRAND-PARENT directory of
the query.
Final remark: the effect of resolving URIs against the parent directory of
the query is achieved by the surprising base URI declaration:
declare base-uri .;
which is not what I would expect.
Conclusion: the way to achieve a resolving of relative URIs against the
parent directory of the query should be achieved by the base URI declaration
.. - and no other value.
Kind regards,
Hans-Juergen
Full example:
Query ( file file:///projects/infospace/pcol/test.xq);
declare base-uri ..;
declare variable $uri external;
string-join((
'query-file: file:///projects/infospace/pcol/test.xq',
concat('static-base-uri: ', static-base-uri()),
concat('resolve-uri(try.xml)=', resolve-uri(try.xml))
), '#xA;')
Output:
query-file: file:///projects/infospace/pcol/test.xq
static-base-uri: file:///C:/projects/infospace
resolve-uri(try.xml)=file:/C:/projects/try.xml
[basex-talk] UPDINDEX not working ?
Hi Christian, I have a problem and I cannot understand what’s happening. I have set UPDINDEX to true, then I have created a database with some XML files in the BaseXGUI. When I look at the DB properties, both Up-to-date and UPDINDEX are true (this is what I want). But if I add some more XML files, using the Add Ressources at the Properties window, the Up-to-date flag becomes false (!) and I cannot understand why. Any hint? I had this problem first using the Java API, so I have decided to test it using the GUI, and I got the same behavior. Thank you in advance, Javier PS : I am using Basex 7.9. Since all is working fine (besides the UPDINDEX issue) I hesitate about upgrading.
Re: [basex-talk] UPDINDEX not working ?
Hi Javier, But if I add some more XML files, using the Add Ressources at the Properties window, the Up-to-date flag becomes false (!) and I cannot understand why. The reason is that UPDINDEX won't update all available index and statistics in BaseX. I have added an explanatory line in [1]. However, I assume that your queries will still take advantage of the value index structures. Have you checked the query info? Christian [1] http://docs.basex.org/wiki/Index#Updates Any hint? I had this problem first using the Java API, so I have decided to test it using the GUI, and I got the same behavior. Thank you in advance, Javier PS : I am using Basex 7.9. Since all is working fine (besides the UPDINDEX issue) I hesitate about upgrading.
[basex-talk] DB size sanity check
Hi all, Database created from 17692 MB: resulting DB size 30450 MB. CHOP is set to false, but for good reasons. TEXTINDEX and ATTRINDEX are true, but FTINDEX false. Can I just sanity check this size of DB? It surprises me a little. (Basex 8.0.2 by the way). Thanks in advance, Constantine Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The Netherlands, Registration No. 33156677, Registered in The Netherlands.
Re: [basex-talk] rest vs. restxq - strange difference
Hi Christian - and thanks for fast response. Latest version 8.11 is in use
(same behaviour as previous). Let me see if I can make a self contained
example.
best,
Lars
2015-05-18 13:40 GMT+02:00 Christian Grün christian.gr...@gmail.com:
Hi Lars,
hm, that's difficult to tell. All I can say is that this sounds
unusual, so I'm coming up with my standard questions: Do you think you
could build us a little example that allows us to reproduce the
problem? Have you tried the latest version of BaseX?
Best,
Christian
On Mon, May 18, 2015 at 1:35 PM, Lars Johnsen yoon...@gmail.com wrote:
I am running a web script in two identical versions (identical as in cut
and paste), one via RESTXQ and one vi REST. The response is different,
and
I wondered what may be the trouble.
For example the output (the URLs only works locally) for
http://ljohnsen:8984/hyphens/mellom
is the same as
http://ljohnsen:8984/rest?run=hyphen-show.xqword=mellom
which is a set of hyphenation data:
mellom
mel - lom 17005
Mel - lom 144
mel - lom. 50
but if mellom is exchanged with nasjonalbiblioteket only the REST
version shows any result, which then is the same as I get experimenting
in
the GUI.
The actual script is added below, and which runs in both versions
(identical apart form the rest and restxq interfaces), it uses full text
search, but results differ when run under the REST-regime.
All the best
Lars G Johnsen
National Library of Norway
module namespace page = 'http://basex.org/modules/web-page';
declare
%rest:path(/hyphens/{$word})
%output:method(html)
function page:show-hyphens($word) {
let $db := db:open('hyphen-data')
let $hyphens := for $hyp in $db/hyphens/hyphens[full contains text
{$word}]
group by $first := $hyp/first, $second := $hyp/second
let $count := count($hyp)
order by xs:int($count) descending
return element p {
attribute freq {$count},
$first, - , $second, $count
}
let $total := sum($hyphens//@freq)
let $div := element div {
element p {$word},
for $hyp in $hyphens
return element div {
attribute class {hyph},
attribute style {font-size:, 1
+round(xs:int($hyp//@freq/data())
div $total,1) || em},
$hyp
}
}
return
html encoding=UTF-8
head
meta http-equiv=Content-Type content=text/html
charset=UTF-8
/
titleOrddelinger/title
/head
body{$div}
/body
/html
};
