Yes, that new BKD/Points based code is definitely something we want in 8 or 7.5 -- it's a big deal. I think it would also be awesome if we had highlighter that could use the Weight.matches() API -- again for either 7.5 or 8. I'm working on this on the UnifiedHighlighter front and Alan from other aspects. ~ David
On Wed, Aug 1, 2018 at 12:51 PM Adrien Grand <[email protected]> wrote: > I was hoping that we would release some bits of this new support for geo > shapes in 7.5 already. We are already very close to being able to index > points, lines and polygons and query for intersection with an envelope. It > would be nice to add support for other relations (eg. disjoint) and queries > (eg. polygon) but the current work looks already useful to me. > > Le mer. 1 août 2018 à 17:00, Robert Muir <[email protected]> a écrit : > >> My only other suggestion is we may want to get Nick's shape stuff into >> the sandbox module at least for 8.0 so that it can be tested out. I >> think it looks like that wouldn't delay any October target though? >> >> On Wed, Aug 1, 2018 at 9:51 AM, Adrien Grand <[email protected]> wrote: >> > I'd like to revive this thread now that these new optimizations for >> > collection of top docs are more usable and enabled by default in >> > IndexSearcher (https://issues.apache.org/jira/browse/LUCENE-8060). Any >> > feedback about starting to work towards releasing 8.0 and targeting >> October >> > 2018? >> > >> > >> > Le jeu. 21 juin 2018 à 09:31, Adrien Grand <[email protected]> a écrit >> : >> >> >> >> Hi Robert, >> >> >> >> I agree we need to make it more usable before 8.0. I would also like to >> >> improve ReqOptSumScorer ( >> https://issues.apache.org/jira/browse/LUCENE-8204) >> >> to leverage impacts so that queries that incorporate queries on feature >> >> fields (https://issues.apache.org/jira/browse/LUCENE-8197) in an >> optional >> >> clause are also fast. >> >> >> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <[email protected]> a écrit : >> >>> >> >>> How can the end user actually use the biggest new feature: impacts and >> >>> BMW? As far as I can tell, the issue to actually implement the >> >>> necessary API changes (IndexSearcher/TopDocs/etc) is still open and >> >>> unresolved, although there are some interesting ideas on it. This >> >>> seems like a really big missing piece, without a proper API, the stuff >> >>> is not really usable. I also can't imagine a situation where the API >> >>> could be introduced in a followup minor release because it would be >> >>> too invasive. >> >>> >> >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien Grand <[email protected]> >> wrote: >> >>> > Hi all, >> >>> > >> >>> > I would like to start discussing releasing Lucene/Solr 8.0. Lucene 8 >> >>> > already >> >>> > has some good changes around scoring, notably cleanups to >> >>> > similarities[1][2][3], indexing of impacts[4], and an >> implementation of >> >>> > Block-Max WAND[5] which, once combined, allow to run queries faster >> >>> > when >> >>> > total hit counts are not requested. >> >>> > >> >>> > [1] https://issues.apache.org/jira/browse/LUCENE-8116 >> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 >> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 >> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 >> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 >> >>> > >> >>> > In terms of bug fixes, there is also a bad relevancy bug[6] which is >> >>> > only in >> >>> > 8.0 because it required a breaking change[7] to be implemented. >> >>> > >> >>> > [6] https://issues.apache.org/jira/browse/LUCENE-8031 >> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 >> >>> > >> >>> > As usual, doing a new major release will also help age out old >> codecs, >> >>> > which >> >>> > in-turn make maintenance easier: 8.0 will no longer need to care >> about >> >>> > the >> >>> > fact that some codecs were initially implemented with a >> random-access >> >>> > API >> >>> > for doc values, that pre-7.0 indices encoded norms differently, or >> that >> >>> > pre-6.2 indices could not record an index sort. >> >>> > >> >>> > I also expect that we will come up with ideas of things to do for >> 8.0 >> >>> > as we >> >>> > feel that the next major is getting closer. In terms of planning, I >> was >> >>> > thinking that we could target something like october 2018, which >> would >> >>> > be >> >>> > 12-13 months after 7.0 and 3-4 months from now. >> >>> > >> >>> > From a Solr perspective, the main change I'm aware of that would be >> >>> > worth >> >>> > releasing a new major is the Star Burst effort. Is it something we >> want >> >>> > to >> >>> > get in for 8.0? >> >>> > >> >>> > Adrien >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
