cancel
Showing results for 
Search instead for 
Did you mean: 

Head's Up! These forums are read-only. All users and content have migrated. Please join us at community.neo4j.com.

Fulltext search on keyword analyzer not working as expected

Hi,

I want to find nodes by creating a full text index using the keyword analyzer. I encounter some weird behavior here.
Here is a sample:

I am creating the index:
call db.index.fulltext.createNodeIndex('myTestIndex',['Node'],['name'],{analyzer:'keyword'})

I add a node:
create (n:Node {name:'SN180-1_2009-07.png'})

I try to find it, using only a part of the name:
call db.index.fulltext.queryNodes('myTestIndex', 'name:(*180-1_2009-07*)') yield node as x
return x

.... and get the node as expected!

I try to find it including the characters at the beginning:
call db.index.fulltext.queryNodes('myTestIndex', 'name:(*SN180-1_2009-07*)') yield node as x
return x

.... and get nothing!

Can anyone explain this behavior? Is it as expected?

Thanks for your help
Frank

4 REPLIES 4

See https://lucene.apache.org/core/8_2_0/queryparser/org/apache/lucene/queryparser/classic/package-summa... - you cannot use wildcards like * as first character in a search term.

Hi Stefan,

The Changelog for Neo 3.5.6 says:

Full-text schema index queries can now start with a leading "*" wildcard, such that, for instance, the token "abcdef" in a property value, can be matched by the query "*def"

...and this seems to be correct, as I get a result when searching like...

call db.index.fulltext.queryNodes('myTestIndex', 'name:(*1_2009-07*)') yield node as x
return x

...but not when searching like...

call db.index.fulltext.queryNodes('myTestIndex', 'name:(1_2009-07*)') yield node as x
return x

...which is as expected.

So the behavior as described in the beginning of this thread is still weird, or more likely a bug....

You're right, we're using reverse indexes as well which allows for a "*" at the beginning.

I've just tried with Neo4j 4.0.0. There the 2nd query works as well. Therefore I suspect that bug was already fixed. Maybe as well in latest 3.5.x releases, but don't know for sure.

F.Y.I:

We are using 3.5.12 and I just upgraded to 3.5.14, but it is definitely not working in these versions.
So it seems it is fixed in 4.0.0 only.