Thanks for that. New version works nicely with full text indexing - and
very fast too!
Noticed that the text index seems to work differently between RESTXQ (not
utilized?) and REST - judging from the response time.
Thanks again for the efforts
Lars
2015-05-19 13:29 GMT+02:00 Christian Grün :
>
> I'll check out how this can be fixed.
So I checked out how to fix it, and I fixed it [1]. Feel free to try
the latest snapshot [2]!
Christian
[1] https://github.com/BaseXdb/basex/issues/1144
[2] http://files.basex.org/releases/latest
> On Mon, May 18, 2015 at 6:46 PM, Lars Johnsen wrote:
>>
Hi Lars,
I think I can confirm the observed behavior: in certain circumstances,
the index properties (stemming etc.) won't be applied to the optimized
full-text query when using RESTXQ.
I'll check out how this can be fixed.
Thanks,
Christian
On Mon, May 18, 2015 at 6:46 PM, Lars Johnsen wrote
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" (=wal
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 S
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
> 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 :
>>
>> It could be that
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
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-t
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
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 :
> Hi Lars,
>
> hm, that's difficult to tell. All I can say is that this sounds
> unus
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, 20
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
13 matches
Mail list logo
