Payloads for each term

2020-10-22 Thread Ankur Goel 
Hi Lucene Devs,
   I have a need to store a sparse feature vector on a per term
basis. The total number of possible dimensions are small (~50) and known at
indexing time. The feature values will be used in scoring along with corpus
statistics. It looks like payloads
 were
created for this exact same purpose but some workaround is needed to
minimize the performance penalty as mentioned on the wiki
 .

An alternative is to override *term frequency* to be a *pointer* in a
*Map* serialized and stored in *BinaryDocValues*. At query time,
the matching *docId *will be used to advance the pointer to the starting
offset of this map*. *The term frequency will be used to perform lookup
into the serialized map to retrieve the* Feature_Vector. *That's my current
plan but I haven't benchmarked it.

The problem that I am trying to solve is to *reduce the index bloat* and
*eliminate* *unnecessary seeks* as currently these ~50 dimensions are
stored as separate fields in the index with very high term overlap and
Lucene does not share Terms dictionary across different fields. This itself
can be a new feature for Lucene but will reqiure lots of work I imagine.

Any ideas are welcome :-)

Thanks
-Ankur

Re: 8.6.3 Release

2020-10-22 Thread David Smiley 
I don't think the status of any page should be in the name of the page --
it breaks links when it changes.  The status can be at the top of the
content.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Thu, Oct 22, 2020 at 10:55 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I guess some convention due to MoinMoin?
>
> On Thu, 22 Oct, 2020, 7:25 pm Jason Gerlowski, 
> wrote:
>
>> On the topic - is there a particular reason behind the convention of
>> having the page titles be named without spaces or periods?  As is they
>> look more like Java classnames than page titles. e.g.
>> "ReleaseNote852" vs "Release Notes: 8.5.2" vs. "8.5.2 Release Notes"
>>
>> On Thu, Oct 22, 2020 at 9:50 AM Jason Gerlowski 
>> wrote:
>> >
>> > I added that "DRAFT-" prefix mostly for the reason Atri mentioned: to
>> > indicate that the page was a WIP.  I thought it might also have the
>> > side benefit of catching the eye of any committers who had Confluence
>> > open and a few minutes to review the content.  The page still has
>> > "DRAFT-" because, as Cassandra suspected, I forgot to update it once
>> > the release was finished.  Fixing now.
>> >
>> > On Thu, Oct 22, 2020 at 9:47 AM Atri Sharma  wrote:
>> > >
>> > > Fair point -- I have changed accordingly.
>> > >
>> > > On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett <
>> casstarg...@gmail.com> wrote:
>> > > >
>> > > > That’s a fair thing to consider, but does it really matter if
>> someone looks at the draft notes pre-release? What would be the harm if
>> users happen across them before they’re done?
>> > > >
>> > > > (And to David’s point, it’s not in the RM steps to fix the page
>> name after release, so it’s pretty easy to forget to do it.)
>> > > > On Oct 22, 2020, 8:31 AM -0500, Atri Sharma ,
>> wrote:
>> > > >
>> > > > I added it since it looked a safe way to indicate that the draft
>> notes
>> > > > are in progress and should not be referred to in case somebody is
>> > > > surfing the release notes.
>> > > >
>> > > > Atri
>> > > >
>> > > > On Thu, Oct 22, 2020 at 6:23 PM David Smiley 
>> wrote:
>> > > >
>> > > >
>> > > > Jason: This is the first time I recall seeing release note pages in
>> Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed
>> suit (following your lead, no doubt) for 8.6. Why? Looking at the page
>> navigation, it's clearly an oddity -- a change. And it's still DRAFT
>> despite it being released.
>> > > >
>> > > > ~ David Smiley
>> > > > Apache Lucene/Solr Search Developer
>> > > > http://www.linkedin.com/in/davidwsmiley
>> > > >
>> > > >
>> > > > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski <
>> gerlowsk...@gmail.com> wrote:
>> > > >
>> > > >
>> > > > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
>> > > > someone please sanity check the summaries there when they get a
>> > > > chance? Would appreciate the review.
>> > > >
>> > > > 8.6.3 is a bit interesting in that Lucene has no changes in this
>> > > > bugfix release. As a result I had to omit the standard phrase in the
>> > > > Solr release notes about there being additional changes at the
>> Lucene
>> > > > level, and change some of the wording in the Lucene announcement to
>> > > > indicate the lack of changes. So that's something to pay particular
>> > > > attention to, if someone can check my wording there.
>> > > >
>> > > > [1]
>> https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
>> > > > [2]
>> https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>> > > >
>> > > > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski <
>> gerlowsk...@gmail.com> wrote:
>> > > >
>> > > >
>> > > > The only one that was previously mentioned as a blocker was
>> > > > SOLR-14835, but from the comments on the ticket it looks like it
>> ended
>> > > > up being purely a cosmetic issue. Andrzej left a comment there
>> > > > suggesting that we "address" this with documentation for 8.6.3 but
>> > > > otherwise leave it as-is.
>> > > >
>> > > > So it looks like we're unblocked on starting the release process.
>> > > > Will begin the preliminary steps this afternoon.
>> > > >
>> > > > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett <
>> casstarg...@gmail.com> wrote:
>> > > >
>> > > >
>> > > > It looks to me like everything for 8.6.3 is resolved now (
>> https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it
>> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
>> Jetty upgrade less compelling to try.
>> > > >
>> > > > Are there any other issues not currently marked for 8.6.3 we’re
>> waiting for before starting the RC?
>> > > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski <
>> gerlowsk...@gmail.com>, wrote:
>> > > >
>> > > > That said, if someone can use 8.6.3, what’s stopping them from
>> going to 8.7 when it’e released?
>> > > >
>> > > >
>> > > > The same things that always stop users from going directly to the
>> > > > latest-and-gre

Re: 8.7 Release Blockers

2020-10-22 Thread Eric Pugh 
If we get down to just SOLR-14067 holding us up, I think it could be moved to 
the next release.  I’ve made a lot of progress, but it may still take a few 
more days to get to done done.

> On Oct 22, 2020, at 4:35 PM, Adrien Grand  wrote:
> 
> Can someone help review this PR to get the above blocker resolved? 
> https://github.com/apache/lucene-solr/pull/2019 
> 
> On Thu, Oct 22, 2020 at 4:11 PM Atri Sharma  > wrote:
> Reminder: This is still a blocker for 8.7:
> 
> https://issues.apache.org/jira/browse/SOLR-14354 
> 
> 
> On Tue, Oct 20, 2020 at 1:02 PM Atri Sharma  > wrote:
> >
> > Hi All,
> >
> > Below are the issues marked as release blockers for 8.7. Can the
> > owners please resolve or move at the earliest?
> >
> > https://issues.apache.org/jira/browse/SOLR-14354 
> > 
> > https://issues.apache.org/jira/browse/SOLR-13973 
> > 
> > https://issues.apache.org/jira/browse/SOLR-14067 
> > 
> >
> > Atri
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> 
> 
> 
> -- 
> Regards,
> 
> Atri
> Apache Concerted
> 
> -- 
> Regards,
> 
> Atri
> Apache Concerted
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Adrien

___
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com  | 
My Free/Busy   
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 


This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.

Re: 8.7 Release Blockers

2020-10-22 Thread Adrien Grand 
Can someone help review this PR to get the above blocker resolved?
https://github.com/apache/lucene-solr/pull/2019

On Thu, Oct 22, 2020 at 4:11 PM Atri Sharma  wrote:

> Reminder: This is still a blocker for 8.7:
>
> https://issues.apache.org/jira/browse/SOLR-14354
>
> On Tue, Oct 20, 2020 at 1:02 PM Atri Sharma  wrote:
> >
> > Hi All,
> >
> > Below are the issues marked as release blockers for 8.7. Can the
> > owners please resolve or move at the earliest?
> >
> > https://issues.apache.org/jira/browse/SOLR-14354
> > https://issues.apache.org/jira/browse/SOLR-13973
> > https://issues.apache.org/jira/browse/SOLR-14067
> >
> > Atri
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
>
>
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Adrien

Re: 8.6.3 Release

2020-10-22 Thread Ishan Chattopadhyaya 
I guess some convention due to MoinMoin?

On Thu, 22 Oct, 2020, 7:25 pm Jason Gerlowski, 
wrote:

> On the topic - is there a particular reason behind the convention of
> having the page titles be named without spaces or periods?  As is they
> look more like Java classnames than page titles. e.g.
> "ReleaseNote852" vs "Release Notes: 8.5.2" vs. "8.5.2 Release Notes"
>
> On Thu, Oct 22, 2020 at 9:50 AM Jason Gerlowski 
> wrote:
> >
> > I added that "DRAFT-" prefix mostly for the reason Atri mentioned: to
> > indicate that the page was a WIP.  I thought it might also have the
> > side benefit of catching the eye of any committers who had Confluence
> > open and a few minutes to review the content.  The page still has
> > "DRAFT-" because, as Cassandra suspected, I forgot to update it once
> > the release was finished.  Fixing now.
> >
> > On Thu, Oct 22, 2020 at 9:47 AM Atri Sharma  wrote:
> > >
> > > Fair point -- I have changed accordingly.
> > >
> > > On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett <
> casstarg...@gmail.com> wrote:
> > > >
> > > > That’s a fair thing to consider, but does it really matter if
> someone looks at the draft notes pre-release? What would be the harm if
> users happen across them before they’re done?
> > > >
> > > > (And to David’s point, it’s not in the RM steps to fix the page name
> after release, so it’s pretty easy to forget to do it.)
> > > > On Oct 22, 2020, 8:31 AM -0500, Atri Sharma ,
> wrote:
> > > >
> > > > I added it since it looked a safe way to indicate that the draft
> notes
> > > > are in progress and should not be referred to in case somebody is
> > > > surfing the release notes.
> > > >
> > > > Atri
> > > >
> > > > On Thu, Oct 22, 2020 at 6:23 PM David Smiley 
> wrote:
> > > >
> > > >
> > > > Jason: This is the first time I recall seeing release note pages in
> Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed
> suit (following your lead, no doubt) for 8.6. Why? Looking at the page
> navigation, it's clearly an oddity -- a change. And it's still DRAFT
> despite it being released.
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley
> > > >
> > > >
> > > > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski <
> gerlowsk...@gmail.com> wrote:
> > > >
> > > >
> > > > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> > > > someone please sanity check the summaries there when they get a
> > > > chance? Would appreciate the review.
> > > >
> > > > 8.6.3 is a bit interesting in that Lucene has no changes in this
> > > > bugfix release. As a result I had to omit the standard phrase in the
> > > > Solr release notes about there being additional changes at the Lucene
> > > > level, and change some of the wording in the Lucene announcement to
> > > > indicate the lack of changes. So that's something to pay particular
> > > > attention to, if someone can check my wording there.
> > > >
> > > > [1]
> https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> > > > [2]
> https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
> > > >
> > > > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski <
> gerlowsk...@gmail.com> wrote:
> > > >
> > > >
> > > > The only one that was previously mentioned as a blocker was
> > > > SOLR-14835, but from the comments on the ticket it looks like it
> ended
> > > > up being purely a cosmetic issue. Andrzej left a comment there
> > > > suggesting that we "address" this with documentation for 8.6.3 but
> > > > otherwise leave it as-is.
> > > >
> > > > So it looks like we're unblocked on starting the release process.
> > > > Will begin the preliminary steps this afternoon.
> > > >
> > > > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett <
> casstarg...@gmail.com> wrote:
> > > >
> > > >
> > > > It looks to me like everything for 8.6.3 is resolved now (
> https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it
> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
> Jetty upgrade less compelling to try.
> > > >
> > > > Are there any other issues not currently marked for 8.6.3 we’re
> waiting for before starting the RC?
> > > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski <
> gerlowsk...@gmail.com>, wrote:
> > > >
> > > > That said, if someone can use 8.6.3, what’s stopping them from going
> to 8.7 when it’e released?
> > > >
> > > >
> > > > The same things that always stop users from going directly to the
> > > > latest-and-greatest: fear of instability from new minor-release
> > > > features, reliance on behavior changed across minor versions,
> breaking
> > > > changes on Lucene elements that don't guarantee backcompat (e.g.
> > > > SOLR-14254), security issues in later versions (new libraries pulled
> > > > in with vulns), etc. There's lots of reasons a given user might want
> > > > to stick on 8.6.x rather than 8.7 (in the short/medium term).
> > > >
> > > > I'm ambivale

Re: 8.7 Release Blockers

2020-10-22 Thread Atri Sharma 
Reminder: This is still a blocker for 8.7:

https://issues.apache.org/jira/browse/SOLR-14354

On Tue, Oct 20, 2020 at 1:02 PM Atri Sharma  wrote:
>
> Hi All,
>
> Below are the issues marked as release blockers for 8.7. Can the
> owners please resolve or move at the earliest?
>
> https://issues.apache.org/jira/browse/SOLR-14354
> https://issues.apache.org/jira/browse/SOLR-13973
> https://issues.apache.org/jira/browse/SOLR-14067
>
> Atri
>
> --
> Regards,
>
> Atri
> Apache Concerted



-- 
Regards,

Atri
Apache Concerted

-- 
Regards,

Atri
Apache Concerted

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 8.6.3 Release

2020-10-22 Thread Jason Gerlowski 
On the topic - is there a particular reason behind the convention of
having the page titles be named without spaces or periods?  As is they
look more like Java classnames than page titles. e.g.
"ReleaseNote852" vs "Release Notes: 8.5.2" vs. "8.5.2 Release Notes"

On Thu, Oct 22, 2020 at 9:50 AM Jason Gerlowski  wrote:
>
> I added that "DRAFT-" prefix mostly for the reason Atri mentioned: to
> indicate that the page was a WIP.  I thought it might also have the
> side benefit of catching the eye of any committers who had Confluence
> open and a few minutes to review the content.  The page still has
> "DRAFT-" because, as Cassandra suspected, I forgot to update it once
> the release was finished.  Fixing now.
>
> On Thu, Oct 22, 2020 at 9:47 AM Atri Sharma  wrote:
> >
> > Fair point -- I have changed accordingly.
> >
> > On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett  
> > wrote:
> > >
> > > That’s a fair thing to consider, but does it really matter if someone 
> > > looks at the draft notes pre-release? What would be the harm if users 
> > > happen across them before they’re done?
> > >
> > > (And to David’s point, it’s not in the RM steps to fix the page name 
> > > after release, so it’s pretty easy to forget to do it.)
> > > On Oct 22, 2020, 8:31 AM -0500, Atri Sharma , wrote:
> > >
> > > I added it since it looked a safe way to indicate that the draft notes
> > > are in progress and should not be referred to in case somebody is
> > > surfing the release notes.
> > >
> > > Atri
> > >
> > > On Thu, Oct 22, 2020 at 6:23 PM David Smiley  wrote:
> > >
> > >
> > > Jason: This is the first time I recall seeing release note pages in 
> > > Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed 
> > > suit (following your lead, no doubt) for 8.6. Why? Looking at the page 
> > > navigation, it's clearly an oddity -- a change. And it's still DRAFT 
> > > despite it being released.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski  
> > > wrote:
> > >
> > >
> > > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> > > someone please sanity check the summaries there when they get a
> > > chance? Would appreciate the review.
> > >
> > > 8.6.3 is a bit interesting in that Lucene has no changes in this
> > > bugfix release. As a result I had to omit the standard phrase in the
> > > Solr release notes about there being additional changes at the Lucene
> > > level, and change some of the wording in the Lucene announcement to
> > > indicate the lack of changes. So that's something to pay particular
> > > attention to, if someone can check my wording there.
> > >
> > > [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> > > [2] 
> > > https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
> > >
> > > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
> > > wrote:
> > >
> > >
> > > The only one that was previously mentioned as a blocker was
> > > SOLR-14835, but from the comments on the ticket it looks like it ended
> > > up being purely a cosmetic issue. Andrzej left a comment there
> > > suggesting that we "address" this with documentation for 8.6.3 but
> > > otherwise leave it as-is.
> > >
> > > So it looks like we're unblocked on starting the release process.
> > > Will begin the preliminary steps this afternoon.
> > >
> > > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett  
> > > wrote:
> > >
> > >
> > > It looks to me like everything for 8.6.3 is resolved now 
> > > (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it 
> > > seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a 
> > > Jetty upgrade less compelling to try.
> > >
> > > Are there any other issues not currently marked for 8.6.3 we’re waiting 
> > > for before starting the RC?
> > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski , 
> > > wrote:
> > >
> > > That said, if someone can use 8.6.3, what’s stopping them from going to 
> > > 8.7 when it’e released?
> > >
> > >
> > > The same things that always stop users from going directly to the
> > > latest-and-greatest: fear of instability from new minor-release
> > > features, reliance on behavior changed across minor versions, breaking
> > > changes on Lucene elements that don't guarantee backcompat (e.g.
> > > SOLR-14254), security issues in later versions (new libraries pulled
> > > in with vulns), etc. There's lots of reasons a given user might want
> > > to stick on 8.6.x rather than 8.7 (in the short/medium term).
> > >
> > > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> > > the worst of the Jetty issue should be mitigated by work on our end -
> > > but I think there's a lot of reasons users might not upgrade as far as
> > > we'd expect/like.
> > >
> > >
> > > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson  
> > > wrote:
> > >
> >

Re: 8.6.3 Release

2020-10-22 Thread Jason Gerlowski 
I added that "DRAFT-" prefix mostly for the reason Atri mentioned: to
indicate that the page was a WIP.  I thought it might also have the
side benefit of catching the eye of any committers who had Confluence
open and a few minutes to review the content.  The page still has
"DRAFT-" because, as Cassandra suspected, I forgot to update it once
the release was finished.  Fixing now.

On Thu, Oct 22, 2020 at 9:47 AM Atri Sharma  wrote:
>
> Fair point -- I have changed accordingly.
>
> On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett  
> wrote:
> >
> > That’s a fair thing to consider, but does it really matter if someone looks 
> > at the draft notes pre-release? What would be the harm if users happen 
> > across them before they’re done?
> >
> > (And to David’s point, it’s not in the RM steps to fix the page name after 
> > release, so it’s pretty easy to forget to do it.)
> > On Oct 22, 2020, 8:31 AM -0500, Atri Sharma , wrote:
> >
> > I added it since it looked a safe way to indicate that the draft notes
> > are in progress and should not be referred to in case somebody is
> > surfing the release notes.
> >
> > Atri
> >
> > On Thu, Oct 22, 2020 at 6:23 PM David Smiley  wrote:
> >
> >
> > Jason: This is the first time I recall seeing release note pages in 
> > Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed 
> > suit (following your lead, no doubt) for 8.6. Why? Looking at the page 
> > navigation, it's clearly an oddity -- a change. And it's still DRAFT 
> > despite it being released.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski  
> > wrote:
> >
> >
> > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> > someone please sanity check the summaries there when they get a
> > chance? Would appreciate the review.
> >
> > 8.6.3 is a bit interesting in that Lucene has no changes in this
> > bugfix release. As a result I had to omit the standard phrase in the
> > Solr release notes about there being additional changes at the Lucene
> > level, and change some of the wording in the Lucene announcement to
> > indicate the lack of changes. So that's something to pay particular
> > attention to, if someone can check my wording there.
> >
> > [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> > [2] https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
> >
> > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
> > wrote:
> >
> >
> > The only one that was previously mentioned as a blocker was
> > SOLR-14835, but from the comments on the ticket it looks like it ended
> > up being purely a cosmetic issue. Andrzej left a comment there
> > suggesting that we "address" this with documentation for 8.6.3 but
> > otherwise leave it as-is.
> >
> > So it looks like we're unblocked on starting the release process.
> > Will begin the preliminary steps this afternoon.
> >
> > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett  
> > wrote:
> >
> >
> > It looks to me like everything for 8.6.3 is resolved now 
> > (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it 
> > seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a 
> > Jetty upgrade less compelling to try.
> >
> > Are there any other issues not currently marked for 8.6.3 we’re waiting for 
> > before starting the RC?
> > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski , 
> > wrote:
> >
> > That said, if someone can use 8.6.3, what’s stopping them from going to 8.7 
> > when it’e released?
> >
> >
> > The same things that always stop users from going directly to the
> > latest-and-greatest: fear of instability from new minor-release
> > features, reliance on behavior changed across minor versions, breaking
> > changes on Lucene elements that don't guarantee backcompat (e.g.
> > SOLR-14254), security issues in later versions (new libraries pulled
> > in with vulns), etc. There's lots of reasons a given user might want
> > to stick on 8.6.x rather than 8.7 (in the short/medium term).
> >
> > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> > the worst of the Jetty issue should be mitigated by work on our end -
> > but I think there's a lot of reasons users might not upgrade as far as
> > we'd expect/like.
> >
> >
> > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson  
> > wrote:
> >
> >
> > For me, there’s a sharp distinction between changing a dependency in a 
> > point release just because there’s a new version, and changing the 
> > dependency because there’s a bug in it. That said, if someone can use 
> > 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would it 
> > make more sense to do the upgrades for 8.7 and get that out the door rather 
> > than backport?
> >
> > FWIW,
> > Erick
> >
> > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski  wrote:
> >
> > Hey all,
> >
> > I wanted to add 2 more blocker

Re: 8.6.3 Release

2020-10-22 Thread Atri Sharma 
Fair point -- I have changed accordingly.

On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett  wrote:
>
> That’s a fair thing to consider, but does it really matter if someone looks 
> at the draft notes pre-release? What would be the harm if users happen across 
> them before they’re done?
>
> (And to David’s point, it’s not in the RM steps to fix the page name after 
> release, so it’s pretty easy to forget to do it.)
> On Oct 22, 2020, 8:31 AM -0500, Atri Sharma , wrote:
>
> I added it since it looked a safe way to indicate that the draft notes
> are in progress and should not be referred to in case somebody is
> surfing the release notes.
>
> Atri
>
> On Thu, Oct 22, 2020 at 6:23 PM David Smiley  wrote:
>
>
> Jason: This is the first time I recall seeing release note pages in 
> Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed 
> suit (following your lead, no doubt) for 8.6. Why? Looking at the page 
> navigation, it's clearly an oddity -- a change. And it's still DRAFT despite 
> it being released.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski  wrote:
>
>
> I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> someone please sanity check the summaries there when they get a
> chance? Would appreciate the review.
>
> 8.6.3 is a bit interesting in that Lucene has no changes in this
> bugfix release. As a result I had to omit the standard phrase in the
> Solr release notes about there being additional changes at the Lucene
> level, and change some of the wording in the Lucene announcement to
> indicate the lack of changes. So that's something to pay particular
> attention to, if someone can check my wording there.
>
> [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> [2] https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>
> On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
> wrote:
>
>
> The only one that was previously mentioned as a blocker was
> SOLR-14835, but from the comments on the ticket it looks like it ended
> up being purely a cosmetic issue. Andrzej left a comment there
> suggesting that we "address" this with documentation for 8.6.3 but
> otherwise leave it as-is.
>
> So it looks like we're unblocked on starting the release process.
> Will begin the preliminary steps this afternoon.
>
> On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett  
> wrote:
>
>
> It looks to me like everything for 8.6.3 is resolved now 
> (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it 
> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a 
> Jetty upgrade less compelling to try.
>
> Are there any other issues not currently marked for 8.6.3 we’re waiting for 
> before starting the RC?
> On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski , 
> wrote:
>
> That said, if someone can use 8.6.3, what’s stopping them from going to 8.7 
> when it’e released?
>
>
> The same things that always stop users from going directly to the
> latest-and-greatest: fear of instability from new minor-release
> features, reliance on behavior changed across minor versions, breaking
> changes on Lucene elements that don't guarantee backcompat (e.g.
> SOLR-14254), security issues in later versions (new libraries pulled
> in with vulns), etc. There's lots of reasons a given user might want
> to stick on 8.6.x rather than 8.7 (in the short/medium term).
>
> I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> the worst of the Jetty issue should be mitigated by work on our end -
> but I think there's a lot of reasons users might not upgrade as far as
> we'd expect/like.
>
>
> On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson  
> wrote:
>
>
> For me, there’s a sharp distinction between changing a dependency in a point 
> release just because there’s a new version, and changing the dependency 
> because there’s a bug in it. That said, if someone can use 8.6.3, what’s 
> stopping them from going to 8.7 when it’e released? Would it make more sense 
> to do the upgrades for 8.7 and get that out the door rather than backport?
>
> FWIW,
> Erick
>
> On Sep 28, 2020, at 1:45 PM, Jason Gerlowski  wrote:
>
> Hey all,
>
> I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
> SOLR-14898. These tickets (while bad bugs in their own right) are
> especially necessary because they work around a Jetty buffer-reuse bug
> (see SOLR-14896) that causes sporadic request failures once triggered.
>
> So that brings the list of 8.6.3 blockers up to: SOLR-14850,
> SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
> work on SOLR-14768!)
>
> Additionally, should we also consider a Jetty upgrade for 8.6.3 in
> light of the issue mentioned above? I know it's atypical for bug-fix
> releases to change deps, but here the bug is serious and tied directly
> to the dep. SOLR-14897 and SOLR-14898 help grea

Re: 8.6.3 Release

2020-10-22 Thread Cassandra Targett 
That’s a fair thing to consider, but does it really matter if someone looks at 
the draft notes pre-release? What would be the harm if users happen across them 
before they’re done?

(And to David’s point, it’s not in the RM steps to fix the page name after 
release, so it’s pretty easy to forget to do it.)
On Oct 22, 2020, 8:31 AM -0500, Atri Sharma , wrote:
> I added it since it looked a safe way to indicate that the draft notes
> are in progress and should not be referred to in case somebody is
> surfing the release notes.
>
> Atri
>
> On Thu, Oct 22, 2020 at 6:23 PM David Smiley  wrote:
> >
> > Jason: This is the first time I recall seeing release note pages in 
> > Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed 
> > suit (following your lead, no doubt) for 8.6. Why? Looking at the page 
> > navigation, it's clearly an oddity -- a change. And it's still DRAFT 
> > despite it being released.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski  
> > wrote:
> > >
> > > I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> > > someone please sanity check the summaries there when they get a
> > > chance? Would appreciate the review.
> > >
> > > 8.6.3 is a bit interesting in that Lucene has no changes in this
> > > bugfix release. As a result I had to omit the standard phrase in the
> > > Solr release notes about there being additional changes at the Lucene
> > > level, and change some of the wording in the Lucene announcement to
> > > indicate the lack of changes. So that's something to pay particular
> > > attention to, if someone can check my wording there.
> > >
> > > [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> > > [2] 
> > > https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
> > >
> > > On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
> > > wrote:
> > > >
> > > > The only one that was previously mentioned as a blocker was
> > > > SOLR-14835, but from the comments on the ticket it looks like it ended
> > > > up being purely a cosmetic issue. Andrzej left a comment there
> > > > suggesting that we "address" this with documentation for 8.6.3 but
> > > > otherwise leave it as-is.
> > > >
> > > > So it looks like we're unblocked on starting the release process.
> > > > Will begin the preliminary steps this afternoon.
> > > >
> > > > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett 
> > > >  wrote:
> > > > >
> > > > > It looks to me like everything for 8.6.3 is resolved now 
> > > > > (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and 
> > > > > it seems from comments in SOLR-14897 and SOLR-14898 that those fixes 
> > > > > make a Jetty upgrade less compelling to try.
> > > > >
> > > > > Are there any other issues not currently marked for 8.6.3 we’re 
> > > > > waiting for before starting the RC?
> > > > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski 
> > > > > , wrote:
> > > > >
> > > > > That said, if someone can use 8.6.3, what’s stopping them from going 
> > > > > to 8.7 when it’e released?
> > > > >
> > > > >
> > > > > The same things that always stop users from going directly to the
> > > > > latest-and-greatest: fear of instability from new minor-release
> > > > > features, reliance on behavior changed across minor versions, breaking
> > > > > changes on Lucene elements that don't guarantee backcompat (e.g.
> > > > > SOLR-14254), security issues in later versions (new libraries pulled
> > > > > in with vulns), etc. There's lots of reasons a given user might want
> > > > > to stick on 8.6.x rather than 8.7 (in the short/medium term).
> > > > >
> > > > > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> > > > > the worst of the Jetty issue should be mitigated by work on our end -
> > > > > but I think there's a lot of reasons users might not upgrade as far as
> > > > > we'd expect/like.
> > > > >
> > > > >
> > > > > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson 
> > > > >  wrote:
> > > > >
> > > > >
> > > > > For me, there’s a sharp distinction between changing a dependency in 
> > > > > a point release just because there’s a new version, and changing the 
> > > > > dependency because there’s a bug in it. That said, if someone can use 
> > > > > 8.6.3, what’s stopping them from going to 8.7 when it’e released? 
> > > > > Would it make more sense to do the upgrades for 8.7 and get that out 
> > > > > the door rather than backport?
> > > > >
> > > > > FWIW,
> > > > > Erick
> > > > >
> > > > > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski  
> > > > > wrote:
> > > > >
> > > > > Hey all,
> > > > >
> > > > > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
> > > > > SOLR-14898. These tickets (while bad bugs in their own right) are
> > > > > especially necessary because they work around a Jetty buffer-reuse bug
> > > > > (see SOLR-14896) th

Re: 8.6.3 Release

2020-10-22 Thread Atri Sharma 
I added it since it looked a safe way to indicate that the draft notes
are in progress and should not be referred to in case somebody is
surfing the release notes.

Atri

On Thu, Oct 22, 2020 at 6:23 PM David Smiley  wrote:
>
> Jason:  This is the first time I recall seeing release note pages in 
> Confluence with a "DRAFT-" prefix.  And I also see that Atri has follow-ed 
> suit (following your lead, no doubt) for 8.6.  Why?  Looking at the page 
> navigation, it's clearly an oddity -- a change.  And it's still DRAFT despite 
> it being released.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski  wrote:
>>
>> I've put together draft Release Notes for 8.6.3 here. [1] [2].  Can
>> someone please sanity check the summaries there when they get a
>> chance?  Would appreciate the review.
>>
>> 8.6.3 is a bit interesting in that Lucene has no changes in this
>> bugfix release.  As a result I had to omit the standard phrase in the
>> Solr release notes about there being additional changes at the Lucene
>> level, and change some of the wording in the Lucene announcement to
>> indicate the lack of changes.  So that's something to pay particular
>> attention to, if someone can check my wording there.
>>
>> [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
>> [2] https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>>
>> On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
>> wrote:
>> >
>> > The only one that was previously mentioned as a blocker was
>> > SOLR-14835, but from the comments on the ticket it looks like it ended
>> > up being purely a cosmetic issue.  Andrzej left a comment there
>> > suggesting that we "address" this with documentation for 8.6.3 but
>> > otherwise leave it as-is.
>> >
>> > So it looks like we're unblocked on starting the release process.
>> > Will begin the preliminary steps this afternoon.
>> >
>> > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett  
>> > wrote:
>> > >
>> > > It looks to me like everything for 8.6.3 is resolved now 
>> > > (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it 
>> > > seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a 
>> > > Jetty upgrade less compelling to try.
>> > >
>> > > Are there any other issues not currently marked for 8.6.3 we’re waiting 
>> > > for before starting the RC?
>> > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski 
>> > > , wrote:
>> > >
>> > > That said, if someone can use 8.6.3, what’s stopping them from going to 
>> > > 8.7 when it’e released?
>> > >
>> > >
>> > > The same things that always stop users from going directly to the
>> > > latest-and-greatest: fear of instability from new minor-release
>> > > features, reliance on behavior changed across minor versions, breaking
>> > > changes on Lucene elements that don't guarantee backcompat (e.g.
>> > > SOLR-14254), security issues in later versions (new libraries pulled
>> > > in with vulns), etc. There's lots of reasons a given user might want
>> > > to stick on 8.6.x rather than 8.7 (in the short/medium term).
>> > >
>> > > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
>> > > the worst of the Jetty issue should be mitigated by work on our end -
>> > > but I think there's a lot of reasons users might not upgrade as far as
>> > > we'd expect/like.
>> > >
>> > >
>> > > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson  
>> > > wrote:
>> > >
>> > >
>> > > For me, there’s a sharp distinction between changing a dependency in a 
>> > > point release just because there’s a new version, and changing the 
>> > > dependency because there’s a bug in it. That said, if someone can use 
>> > > 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would 
>> > > it make more sense to do the upgrades for 8.7 and get that out the door 
>> > > rather than backport?
>> > >
>> > > FWIW,
>> > > Erick
>> > >
>> > > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski  
>> > > wrote:
>> > >
>> > > Hey all,
>> > >
>> > > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
>> > > SOLR-14898. These tickets (while bad bugs in their own right) are
>> > > especially necessary because they work around a Jetty buffer-reuse bug
>> > > (see SOLR-14896) that causes sporadic request failures once triggered.
>> > >
>> > > So that brings the list of 8.6.3 blockers up to: SOLR-14850,
>> > > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
>> > > work on SOLR-14768!)
>> > >
>> > > Additionally, should we also consider a Jetty upgrade for 8.6.3 in
>> > > light of the issue mentioned above? I know it's atypical for bug-fix
>> > > releases to change deps, but here the bug is serious and tied directly
>> > > to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the
>> > > Jetty bug is likely still a problem for users making requests that
>> > > match a specific (albeit ra

Re: 8.6.3 Release

2020-10-22 Thread David Smiley 
Jason:  This is the first time I recall seeing release note pages in
Confluence with a "DRAFT-" prefix.  And I also see that Atri has follow-ed
suit (following your lead, no doubt) for 8.6.  Why?  Looking at the page
navigation, it's clearly an oddity -- a change.  And it's still DRAFT
despite it being released.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski 
wrote:

> I've put together draft Release Notes for 8.6.3 here. [1] [2].  Can
> someone please sanity check the summaries there when they get a
> chance?  Would appreciate the review.
>
> 8.6.3 is a bit interesting in that Lucene has no changes in this
> bugfix release.  As a result I had to omit the standard phrase in the
> Solr release notes about there being additional changes at the Lucene
> level, and change some of the wording in the Lucene announcement to
> indicate the lack of changes.  So that's something to pay particular
> attention to, if someone can check my wording there.
>
> [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> [2]
> https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>
> On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski 
> wrote:
> >
> > The only one that was previously mentioned as a blocker was
> > SOLR-14835, but from the comments on the ticket it looks like it ended
> > up being purely a cosmetic issue.  Andrzej left a comment there
> > suggesting that we "address" this with documentation for 8.6.3 but
> > otherwise leave it as-is.
> >
> > So it looks like we're unblocked on starting the release process.
> > Will begin the preliminary steps this afternoon.
> >
> > On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett 
> wrote:
> > >
> > > It looks to me like everything for 8.6.3 is resolved now (
> https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it
> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
> Jetty upgrade less compelling to try.
> > >
> > > Are there any other issues not currently marked for 8.6.3 we’re
> waiting for before starting the RC?
> > > On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski <
> gerlowsk...@gmail.com>, wrote:
> > >
> > > That said, if someone can use 8.6.3, what’s stopping them from going
> to 8.7 when it’e released?
> > >
> > >
> > > The same things that always stop users from going directly to the
> > > latest-and-greatest: fear of instability from new minor-release
> > > features, reliance on behavior changed across minor versions, breaking
> > > changes on Lucene elements that don't guarantee backcompat (e.g.
> > > SOLR-14254), security issues in later versions (new libraries pulled
> > > in with vulns), etc. There's lots of reasons a given user might want
> > > to stick on 8.6.x rather than 8.7 (in the short/medium term).
> > >
> > > I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> > > the worst of the Jetty issue should be mitigated by work on our end -
> > > but I think there's a lot of reasons users might not upgrade as far as
> > > we'd expect/like.
> > >
> > >
> > > On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson <
> erickerick...@gmail.com> wrote:
> > >
> > >
> > > For me, there’s a sharp distinction between changing a dependency in a
> point release just because there’s a new version, and changing the
> dependency because there’s a bug in it. That said, if someone can use
> 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would it
> make more sense to do the upgrades for 8.7 and get that out the door rather
> than backport?
> > >
> > > FWIW,
> > > Erick
> > >
> > > On Sep 28, 2020, at 1:45 PM, Jason Gerlowski 
> wrote:
> > >
> > > Hey all,
> > >
> > > I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
> > > SOLR-14898. These tickets (while bad bugs in their own right) are
> > > especially necessary because they work around a Jetty buffer-reuse bug
> > > (see SOLR-14896) that causes sporadic request failures once triggered.
> > >
> > > So that brings the list of 8.6.3 blockers up to: SOLR-14850,
> > > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
> > > work on SOLR-14768!)
> > >
> > > Additionally, should we also consider a Jetty upgrade for 8.6.3 in
> > > light of the issue mentioned above? I know it's atypical for bug-fix
> > > releases to change deps, but here the bug is serious and tied directly
> > > to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the
> > > Jetty bug is likely still a problem for users making requests that
> > > match a specific (albeit rare) profile. Anyone have thoughts?
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > On Fri, Sep 25, 2020 at 12:28 AM Houston Putman <
> houstonput...@gmail.com> wrote:
> > >
> > >
> > > If I recall correctly, thats a step in the release wizard.
> > >
> > > After checking, I think this fits the bill:
> > >
> https://github.com/apache/lucene-solr/blob/master/de

Re: PointInSetQuery dose not terminate early if DocIdSetBuilder's bitSet is null

2020-10-22 Thread hacker win7 
Hi, Adrien Grand

Could we check the result after BKD.intersect() inner the 
PointInSetQuery.scorer(), if the result.build.iterator() the first next doc is 
already NO_MORE_DOCS ?  We need not to build scorer with new 
ConstantScoreScorer() , just return null. In this way, the BooleanQuery for AND 
can terminate early and the subsequent clauses should not evaluate to build 
scorer to waste extra compute resource.

This terminate more early on PointInSetQuery can be good at a number match 
leading clause of boolean query search mode with a high percent requests whose 
number match hits is empty.


hacker win7
hackersw...@gmail.com



> On Sep 28, 2020, at 21:06, Adrien Grand  wrote:
> 
> What are you storing in your points? If you are storing numbers, I wonder if 
> a better approach to this problem might be to start leveraging 
> IndexOrDocValuesQuery and scorerSupplier() for point-in-set queries like we 
> did for range queries.
> 
> The approach you suggested would help in some cases, but I'm a bit unhappy 
> that it would be quite fragile, e.g. SubQuery1 AND SubQuery2 might become 
> faster as we could save evaluating matches of SubQuery2 but SubQuery2 AND 
> SubQuery1 would still be slow.
> 
> On Mon, Sep 28, 2020 at 5:02 AM hacker win7  > wrote:
> Hi Lucene developers,
> 
> In Lucene-7.7.0, I find that in `PointInSetQuery.createWeight()`, and in the 
> method `scorer()` after `values.intersect()`, if the `result.bitSet` is null, 
> then the `result.build()` would use `concat()` to generate a Buffer and the 
> length is 1. And the element of array is `NO_MORE_DOCS`.
> 
> Why not return null in the method `scorer()` if `result.bitSet` is null ?
> 
> In the following case:
> 
> SubQuery1 AND SubQuery2 AND SubQuery3 …...
> 
> BooleanWeight.scorerSupplier() -> 
> 
> the first subScorer of query is PointInSetQuery -> 
> 
> scorer() ->
> 
> after intersect if result.bitSet is null, there is no specific point value at 
> all then return null ->
> 
> 
> This will terminate early in the BooleanWeight.scoreSupplier() because 
> subScore is null and the boolean clause is required
> 
> The following SubQuery2, SubQuery3, SubQuery4 …. Need not to call 
> scorerSupplier() to build scorer
> 
> 
> hacker win7
> hackersw...@gmail.com 
> 
> 
> 
> 
> 
> -- 
> Adrien

Re: Seeking Inputs for Release Highlights

2020-10-22 Thread Adrien Grand 
Thanks, I added some entries to the Lucene release notes.

On Thu, Oct 22, 2020 at 1:23 PM Atri Sharma  wrote:

> Hi Adrien,
>
> Please find below:
>
> https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote87
> https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote87
>
> On Thu, Oct 22, 2020 at 4:37 PM Adrien Grand  wrote:
> >
> > Hi Atri, if you can create a page in the wiki, I'll be happy to add some
> items to the release highlights. I have the compression for stored fields
> improvements in mind as well as the speedups for queries sorted by a field
> indexed with points.
> >
> > On Thu, Oct 22, 2020 at 12:54 PM Atri Sharma  wrote:
> >>
> >> Hi All,
> >>
> >> Can we come up with the items we wish to highlight in 8.7 release notes?
> >>
> >> Atri
> >>
> >> --
> >> Regards,
> >>
> >> Atri
> >> Apache Concerted
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> >
> > --
> > Adrien
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Adrien

Re: Seeking Inputs for Release Highlights

2020-10-22 Thread Atri Sharma 
Hi Adrien,

Please find below:

https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote87
https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote87

On Thu, Oct 22, 2020 at 4:37 PM Adrien Grand  wrote:
>
> Hi Atri, if you can create a page in the wiki, I'll be happy to add some 
> items to the release highlights. I have the compression for stored fields 
> improvements in mind as well as the speedups for queries sorted by a field 
> indexed with points.
>
> On Thu, Oct 22, 2020 at 12:54 PM Atri Sharma  wrote:
>>
>> Hi All,
>>
>> Can we come up with the items we wish to highlight in 8.7 release notes?
>>
>> Atri
>>
>> --
>> Regards,
>>
>> Atri
>> Apache Concerted
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Adrien

-- 
Regards,

Atri
Apache Concerted

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Seeking Inputs for Release Highlights

2020-10-22 Thread Adrien Grand 
Hi Atri, if you can create a page in the wiki, I'll be happy to add some
items to the release highlights. I have the compression for stored fields
improvements in mind as well as the speedups for queries sorted by a field
indexed with points.

On Thu, Oct 22, 2020 at 12:54 PM Atri Sharma  wrote:

> Hi All,
>
> Can we come up with the items we wish to highlight in 8.7 release notes?
>
> Atri
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Adrien

Seeking Inputs for Release Highlights

2020-10-22 Thread Atri Sharma 
Hi All,

Can we come up with the items we wish to highlight in 8.7 release notes?

Atri

-- 
Regards,

Atri
Apache Concerted

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org