Custom analyzer with traversal queries
florent@...
Hello everyone,
As it's my first post, I'd first thank you all for your work ! It has been pretty neat to discover all of the work !
We've started to investigate the use of custom analyzers in our schema (-> https://docs.janusgraph.org/v0.5/index-backend/field-mapping/#for-elasticsearch), where ES is used as an indexing backend.
From what I've seen, initial selections will indeed use the index (e.g. `traversal().V().has(...)`). However, it isn't always used, and sometimes the janusgraph implementation of the predicate is used (e.g. when `traversal().V(idx1, idx2, ...).has(...)`). In this latter case, it's the predicates as implemented here that are run. For text fields, it looks like a tokenization and lower-casing are perform by them directly.
I haven't seen mention of this case in the documentation. So, I'm wondering if my observations are valid.
If so, is there a way to force the usage of ES indices? An IDs query could be way to implement such feature (at least for ES).
All the best,
Flo
As it's my first post, I'd first thank you all for your work ! It has been pretty neat to discover all of the work !
We've started to investigate the use of custom analyzers in our schema (-> https://docs.janusgraph.org/v0.5/index-backend/field-mapping/#for-elasticsearch), where ES is used as an indexing backend.
From what I've seen, initial selections will indeed use the index (e.g. `traversal().V().has(...)`). However, it isn't always used, and sometimes the janusgraph implementation of the predicate is used (e.g. when `traversal().V(idx1, idx2, ...).has(...)`). In this latter case, it's the predicates as implemented here that are run. For text fields, it looks like a tokenization and lower-casing are perform by them directly.
I haven't seen mention of this case in the documentation. So, I'm wondering if my observations are valid.
If so, is there a way to force the usage of ES indices? An IDs query could be way to implement such feature (at least for ES).
All the best,
Flo