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

option to sort by other fields #110

Closed
mschoch opened this issue Oct 13, 2014 · 12 comments
Closed

option to sort by other fields #110

mschoch opened this issue Oct 13, 2014 · 12 comments
Milestone

Comments

@mschoch
Copy link
Contributor

mschoch commented Oct 13, 2014

Sometimes its useful for applications to want the search results sorted by another field, often a date or numeric value.

@AndrewVos
Copy link

I wanted to do a spike and see if bleve will work for my client, but they definitely need sorting.

At the moment they're only really sorting on "price", which is a float.

@mschoch
Copy link
Contributor Author

mschoch commented Oct 24, 2014

Some interesting bits about how this is done in Lucene: http://blog.trifork.com/2011/10/27/introducing-lucene-index-doc-values/

@dorsha
Copy link

dorsha commented Oct 18, 2015

We would love to have sort functionality on other fields as well (for pagination and etc.)

@meirwah
Copy link

meirwah commented Oct 19, 2015

pagination without sorting is a bit lacking.. is this feature planned anytime soon?

@mschoch
Copy link
Contributor Author

mschoch commented Oct 19, 2015

No one is currently working on it. At the moment I'm focused exclusively on performance, as for our use case sorting/pagination by score is sufficient, but indexing throughput is too low to be usable.

Its not a small job, but its not impossible for someone else to take a look at it in parallel. There are two main pieces.

  1. A new implementation of the Collector interface, which is responsible for looking at all the scored "hits" and deciding which ones to keep and return to the user. The current impl looks at score and keeps the top N, after skipping over M hits. The new impl would look at the "sort" field(s), and keep the highest/lowest results, possibly also breaking ties by using the score.
  2. Part 1 sounds straightforward, but the missing piece is how does it access the value for the sort field(s). Probably some interfaces need to change to accommodate this, as when users request stored fields we don't load them till later in the process. Some thought needs to be put into the most efficient way to collect these sort values while we execute the search.

@slavikm
Copy link
Contributor

slavikm commented Feb 10, 2016

@mschoch is anyone working on this currently? I would like to take a stub at this as we need sort for other fields.

@caseymrm
Copy link
Contributor

@slavikm I saw you had one collector commit, is this something you're actively working on?

@slavikm
Copy link
Contributor

slavikm commented May 27, 2016

@caseymrm I started, then had to stop for a while (other stuff came up) and now I'm getting back to it. Hopefully will try and commit something next week.

@nadoo
Copy link

nadoo commented Jun 12, 2016

really need this feature, hope it will be implemented soon. thank you! @slavikm .

@yonderblue
Copy link

yonderblue commented Jun 25, 2016

👍 as a need to be able to use the lib

@mschoch mschoch added this to the 1.0 milestone Jun 26, 2016
@mschoch
Copy link
Contributor Author

mschoch commented Jun 26, 2016

Yes, I understand this is important. We will prioritize this and make sure we at least get the API to do this into 1.0.

@yonderblue
Copy link

I love to see the work here! :D

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

Successfully merging a pull request may close this issue.

8 participants