Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to implement like lucene where we can search fieldA = ABC AND fieldB = BCD #13

Open
yashhema opened this issue Feb 22, 2018 · 3 comments

Comments

@yashhema
Copy link

Hello,
Say my data consists of a text and it also has some attributes (like Info1 , Info2 etc)
I should be able to do search both on any word present or any of the attributes.
Can you suggest how it can be implemented ?

@markpapadakis
Copy link
Member

markpapadakis commented Mar 13, 2018

�Hello,

You can just index those attributes like other terms, by, for example, prefixing the term with an appropriate prefix. For example, info1:dog, info2:black
and then you can search for ( info1:dog OR info1:cat ) animals
Or
fielda:ABC AND fieldb:BCD

Does this answer your question?

@yashhema
Copy link
Author

I am interested in implement document like interface (Like there is in lucene). so we can have fields of different types like int, long . So we can save dates and do range queries on dates and numbers.
I saw the comments in Index.h regarding a place holder for having multiple fields.
Can you provide some pointers on how should i go about implementing that.

@markpapadakis
Copy link
Member

This is currently not supported in Trinity, although it shouldn't be hard to extend it to support it. Lucene initially supported range queries (e.g numeric ranges) by partitioning the values space and then using a simple space-partition to token scheme, though later they switched to a more generic, and more efficient, scheme where they encode a per-segment representation for a values-space and query that instead.
You should be able to do that as well, or whatever else really. It's just that we didn't need that feature, and for cases where we need something similar, we have an in-memory per-document store for quick-lookups for filtering and whatnot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants