You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Martin Gainty <mg...@hotmail.com> on 2017/05/01 10:30:28 UTC

Re: Release 6.6

i was wondering if there was a specific test for SpanPayloadCheckQuery method


matches = payloadToMatch.get(upto).bytesEquals(payload);


the only implementation i could locate was in collectLeaf of SpanPayloadCheckQuery


I will submit JIRA with Patch


as a CS *dinosaur* I am more familiar with LISP for dissecting sentence fragments (what we called phenomes) than current SEO implementations


Can you suggest a book to read to better understand Lucenes pattern dissection and match algorithms?


Many Thanks for helpful guidance

Martin
______________________________________________



________________________________
From: Erik Hatcher <er...@gmail.com>
Sent: Sunday, April 30, 2017 2:06 PM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Martin -

I have to admit to still being unsure what the gist is here - is there a bug?   Apologies for not catching what you’re saying/showing here.  Again, as far as I can tell SpanPayloadCheckQuery is working as expected now.

I’m going to focus purely on SOLR-1485 this week to get it committed for 6.6.  If there is an issue to address with your work would you please open a JIRA and include your patch there?

Thanks,
Erik


On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>> wrote:

Mornin' Erik

there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:

static class VerifyingCollector implements SpanCollector {
    List<BytesRef> payloads = new ArrayList<>();
    @Override
    public void collectLeaf(PostingsEnum postings, int position, Term term) throws IOException {
     ....
     }
}

the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf for query

//initialise term

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before term1=new org.apache.lucene.index.Term('field','withPayload')");
org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field", "withPayload");
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233 term1="+term1);

//assume position is 5
    int position=5;
    log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235 position="+position);

    BytesRef pay = new BytesRef("pos: " + position);
    log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237 pay="+pay);

//build spanQuery with term parameter
    org.apache.lucene.search.spans.SpanQuery spanQuery1 = new SpanTermQuery(term1);
    log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239 spanQuery1="+spanQuery1);

//add BytesRef to payloadToMatch list
    java.util.List<org.apache.lucene.util.BytesRef> payloadToMatch=new java.util.ArrayList<org.apache.lucene.util.BytesRef>();
    log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241 payloadToMatch="+payloadToMatch);
    payloadToMatch.add(pay);


//build SpanPayloadCheckQuery

query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
(org.apache.lucene.search.spans.SpanQuery)query,
(java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249 query="+query);

//build lucene Directory (TODO: we should use an existing directory with REAL test-data)
org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());

//build SegmentReader from Directory
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251 ram="+ram);
SegmentReader reader = getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253 reader="+reader);

//populate SlowCompositeReaderWrapper with SegmentReader
    org.apache.lucene.index.LeafReader sr = org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
    log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255 sr="+sr);

//add term to SegmentReader postings
org.apache.lucene.index.PostingsEnum postings = sr.postings(term1, PostingsEnum.PAYLOADS);

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);

//display the parameters for collectLeaf method for query:
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where position="+position);

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
    try
    { //public void collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,       //org.apache.lucene.index.Term term) throws java.io.IOException {
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1);
}
catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException ="+ioe.getMessage()); }

collectLeaf is the only method that compares matches=payloadToMatch.get(upto).bytesEquals(payload)

to determine "match"

unless of course match between individual payload and payloadToMatch is tested elsewhere ?

WDYT?
Martin
______________________________________________



________________________________
From: Erik Hatcher <er...@gmail.com>>
Sent: Saturday, April 29, 2017 7:58 PM
To: Lucene/Solr dev
Subject: Re: Release 6.6

Martin -

Interesting test but I couldn’t copy/paste it in to try it out as it uses some logging and APIs that aren’t already in the project and classpath of these lucene tests within that queries module (within IntelliJ, mind you).

I was able to resolve the misunderstanding (and .equals/.hashCode bugs) so everything is working as expected with SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or confirming that it is working properly at a lower level?

Erik


On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>> wrote:

Martin Gainty has shared a OneDrive file with you. To view it, click the link below.


<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
[https://r1.res.office365.com/owa/prem/images/dc-generic_20.png]<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>

TestPayloadCheckQuery.java<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>



attached

I coded this last nite so it is "quick and dirty"

in any case let me know if  testSpanPayloadCheck() method modification properly addresses your situation

Thanks!
Martin
______________________________________________



________________________________
From: Erik Hatcher <er...@gmail.com>>
Sent: Saturday, April 29, 2017 8:58 AM
To: dev@lucene.apache.org<ma...@lucene.apache.org>
Subject: Re: Release 6.6

Martin - there is a test class specifically for this query.   See the recent commits I've made to test it further fixing .equals/.hashCode and rewrite.

Can you send your full test code?

   Erik

On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>> wrote:

when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about to reply just run that TestCase
(until i discovered there wasnt any!)

i'll start the bidding at 1 dinar for TestCase org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
  @org.junit.Test
  public void testSpanPayloadCheck() throws Exception


    //now lets test the collectLeaf for query
    //of course calling Base Class SpanPayloadCheckQuery to construct query

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);

    try
    { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,              //org.apache.lucene.index.Term term) throws java.io.IOException {
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1);
}
catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException ="+ioe.getMessage()); }


unless of course anyone has a better idea to test collectLeaf ?
Martin
______________________________________________



________________________________
From: Erik Hatcher <er...@gmail.com>>
Sent: Tuesday, April 25, 2017 7:57 PM
To: dev@lucene.apache.org<ma...@lucene.apache.org>
Subject: Re: Release 6.6

Probably no bribe needed, but an updated patch would be a good start (or will the 2.5 year old patch still apply and be acceptable as-is?)

Erik

On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>> wrote:

Who do I have to bribe to get SOLR-629 included?

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

wunder
Walter Underwood
wunder@wunderwood.org<ma...@wunderwood.org>
http://observer.wunderwood.org/  (my blog)


On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <ic...@gmail.com>> wrote:

Hi,
We have lots of changes, optimizations, bug fixes for 6.6. I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 release).

I can volunteer to release this, and I can cut the release branch around 4th May, in order to let some time for devs to finish current issues.

What do you think?

Regards,
Ishan


Re: Release 6.6

Posted by Uwe Schindler <uw...@thetaphi.de>.
Ok from my side! Uwe

Am 14. Mai 2017 11:04:33 MESZ schrieb Steve Rowe <sa...@gmail.com>:
>Ishan,
>
>Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 for
>6.6?
>
>--
>Steve
>www.lucidworks.com
>
>> On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
>wrote:
>> 
>> Ok thanks Ishan.
>> 
>> Le 12 mai 2017 18:44, "Ishan Chattopadhyaya"
><ic...@gmail.com> a écrit :
>> Sure, Jim. Please go ahead!
>> 
>> On Fri, May 12, 2017 at 10:01 PM, jim ferenczi
><ji...@gmail.com> wrote:
>> Hi,
>> Would be great to have
>https://issues.apache.org/jira/browse/LUCENE-7824 included for 6.6. Can
>I merge the fix this week end Ishan ?
>> 
>> 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya
><ic...@gmail.com>:
>> Done, Adrien. Thanks!
>> 
>> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>wrote:
>> Ishan, wdyt about running addVersion on the branch_6x/master as well?
>I think it would help realize that the 6.6 branch has been cut when
>looking at the CHANGES.txt file and not forget about backporting?
>> 
>> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya
><ic...@gmail.com> a écrit :
>> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>bugfixes to the branch, if needed.
>> Planning to build the first RC on 15 May. Please let me know if there
>are any objections.
>> 
>> Thanks,
>> Ishan
>> 
>> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya
><ic...@gmail.com> wrote:
>> Planning to cut the release branch in another 10-12 hours.
>> 
>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>wrote:
>> i was wondering if there was a specific test for
>SpanPayloadCheckQuery method
>> 
>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>> 
>> 
>> 
>> the only implementation i could locate was in collectLeaf of
>SpanPayloadCheckQuery
>> 
>> 
>> I will submit JIRA with Patch
>> 
>> 
>> as a CS *dinosaur* I am more familiar with LISP for dissecting
>sentence fragments (what we called phenomes) than current SEO
>implementations
>> 
>> 
>> Can you suggest a book to read to better understand Lucenes pattern
>dissection and match algorithms?
>> 
>> 
>> Many Thanks for helpful guidance
>> Martin  
>> ______________________________________________ 
>> 
>> 
>> 
>> From: Erik Hatcher <er...@gmail.com>
>> Sent: Sunday, April 30, 2017 2:06 PM
>> 
>> To: dev@lucene.apache.org
>> Subject: Re: Release 6.6
>>  
>> Martin -
>> 
>> I have to admit to still being unsure what the gist is here - is
>there a bug?   Apologies for not catching what you’re saying/showing
>here.  Again, as far as I can tell SpanPayloadCheckQuery is working as
>expected now.  
>> 
>> I’m going to focus purely on SOLR-1485 this week to get it committed
>for 6.6.  If there is an issue to address with your work would you
>please open a JIRA and include your patch there?
>> 
>> Thanks,
>> Erik
>> 
>> 
>>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>wrote:
>>> 
>>> Mornin' Erik
>>> 
>>> there is a collectLeaf  override in
>org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never
>called:
>>> 
>>> static class VerifyingCollector implements SpanCollector {
>>>     List<BytesRef> payloads = new ArrayList<>();
>>>     @Override
>>>     public void collectLeaf(PostingsEnum postings, int position,
>Term term) throws IOException {
>>>      ....
>>>      }
>>> }
>>> 
>>> the modification in
>org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests
>collectLeaf for query
>>> 
>>> //initialise term
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>before term1=new org.apache.lucene.index.Term('field','withPayload')");
>>> org.apache.lucene.index.Term term1=new
>org.apache.lucene.index.Term("field", "withPayload");
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>term1="+term1);
>>> 
>>> //assume position is 5
>>>     int position=5;
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>position="+position);
>>> 
>>>     BytesRef pay = new BytesRef("pos: " + position);
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>pay="+pay);
>>> 
>>> //build spanQuery with term parameter
>>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>SpanTermQuery(term1);
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>spanQuery1="+spanQuery1);
>>> 
>>> //add BytesRef to payloadToMatch list
>>>     java.util.List<org.apache.lucene.util.BytesRef>
>payloadToMatch=new
>java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>payloadToMatch="+payloadToMatch);
>>>     payloadToMatch.add(pay);
>>> 
>>> //build SpanPayloadCheckQuery
>>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>> (org.apache.lucene.search.spans.SpanQuery)query,
>>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>query="+query);
>>> 
>>> //build lucene Directory (TODO: we should use an existing directory
>with REAL test-data)
>>> org.apache.lucene.store.Directory ram =
>newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>> 
>>> //build SegmentReader from Directory
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>ram="+ram);
>>> SegmentReader reader =
>getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>reader="+reader);
>>> 
>>> //populate SlowCompositeReaderWrapper with SegmentReader
>>>     org.apache.lucene.index.LeafReader sr =
>org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>sr="+sr);
>>> 
>>> //add term to SegmentReader postings
>>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>PostingsEnum.PAYLOADS);
>>> 
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>before
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) where
>postings="+postings);
>>> 
>>> //display the parameters for collectLeaf method for query:
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>before
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) where
>position="+position);
>>> 
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>before
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) where
>term1="+term1);
>>>     try
>>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>postings, int position,       //org.apache.lucene.index.Term term)
>throws java.io.IOException {
>>>
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1);
>>> }
>>> catch(java.io.IOException ioe) {
>log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>IOException ="+ioe.getMessage()); }
>>> 
>>> collectLeaf is the only method that compares
>matches=payloadToMatch.get(upto).bytesEquals(payload)
>>> to determine "match"
>>> 
>>> unless of course match between individual payload and payloadToMatch
>is tested elsewhere ?
>>> 
>>> WDYT?
>>> Martin 
>>> ______________________________________________ 
>>> 
>>> 
>>> 
>>> From: Erik Hatcher <er...@gmail.com>
>>> Sent: Saturday, April 29, 2017 7:58 PM
>>> To: Lucene/Solr dev
>>> Subject: Re: Release 6.6
>>>  
>>> Martin -
>>> 
>>> Interesting test but I couldn’t copy/paste it in to try it out as it
>uses some logging and APIs that aren’t already in the project and
>classpath of these lucene tests within that queries module (within
>IntelliJ, mind you).
>>> 
>>> I was able to resolve the misunderstanding (and .equals/.hashCode
>bugs) so everything is working as expected with SpanPayloadCheckQuery
>for me now.   Do your tests point out an issue?   Or confirming that it
>is working properly at a lower level?
>>> 
>>> Erik
>>> 
>>> 
>>>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>wrote:
>>>> 
>>>> Martin Gainty has shared a OneDrive file with you. To view it,
>click the link below.
>>>>  
>>>> TestPayloadCheckQuery.java
>>>> attached
>>>> 
>>>> I coded this last nite so it is "quick and dirty"
>>>> 
>>>> in any case let me know if  testSpanPayloadCheck() method
>modification properly addresses your situation
>>>> 
>>>> Thanks!
>>>> Martin 
>>>> ______________________________________________ 
>>>> 
>>>> 
>>>> 
>>>> From: Erik Hatcher <er...@gmail.com>
>>>> Sent: Saturday, April 29, 2017 8:58 AM
>>>> To: dev@lucene.apache.org
>>>> Subject: Re: Release 6.6
>>>>  
>>>> Martin - there is a test class specifically for this query.   See
>the recent commits I've made to test it further fixing
>.equals/.hashCode and rewrite. 
>>>> 
>>>> Can you send your full test code?
>>>> 
>>>>    Erik
>>>> 
>>>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>wrote:
>>>> 
>>>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
>was about to reply just run that TestCase
>>>>> (until i discovered there wasnt any!)
>>>>> 
>>>>> i'll start the bidding at 1 dinar for TestCase
>org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>   @org.junit.Test
>>>>>   public void testSpanPayloadCheck() throws Exception
>>>>> 
>>>>>     //now lets test the collectLeaf for query
>>>>>     //of course calling Base Class SpanPayloadCheckQuery to
>construct query
>>>>> 
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>before
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) where
>postings="+postings);
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>before
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) where
>position="+position);
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>before
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) where
>term1="+term1);
>>>>> 
>>>>>     try
>>>>>     { //test public void
>collectLeaf(org.apache.lucene.index.PostingsEnum postings, int
>position,              //org.apache.lucene.index.Term term) throws
>java.io.IOException {
>>>>>
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1);
>>>>> }
>>>>> catch(java.io.IOException ioe) {
>log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>(int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>IOException ="+ioe.getMessage()); }
>>>>> 
>>>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>> Martin 
>>>>> ______________________________________________ 
>>>>> 
>>>>> 
>>>>> 
>>>>> From: Erik Hatcher <er...@gmail.com>
>>>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>> To: dev@lucene.apache.org
>>>>> Subject: Re: Release 6.6
>>>>>  
>>>>> Probably no bribe needed, but an updated patch would be a good
>start (or will the 2.5 year old patch still apply and be acceptable
>as-is?)
>>>>> 
>>>>> Erik
>>>>> 
>>>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood
><wu...@wunderwood.org> wrote:
>>>>>> 
>>>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>> 
>>>>>> wunder
>>>>>> Walter Underwood
>>>>>> wunder@wunderwood.org
>>>>>> http://observer.wunderwood.org/  (my blog)
>>>>>> 
>>>>>> 
>>>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya
><ic...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd
>like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>before 7.0 release).
>>>>>>> 
>>>>>>> I can volunteer to release this, and I can cut the release
>branch around 4th May, in order to let some time for devs to finish
>current issues.
>>>>>>> 
>>>>>>> What do you think?
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Ishan
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>For additional commands, e-mail: dev-help@lucene.apache.org

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: Release 6.6

Posted by Erick Erickson <er...@gmail.com>.
Ditto!


On Mon, Jun 5, 2017 at 11:10 AM, Mike Drob <md...@apache.org> wrote:
> Thanks for putting this together, Ishan!
>
> On Mon, Jun 5, 2017 at 1:05 PM, Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
>>
>> Hi all,
>> I've updated the release notes here:
>> https://wiki.apache.org/lucene-java/ReleaseNote66
>> https://wiki.apache.org/solr/ReleaseNote66
>>
>> Please review / feel free to edit.
>> I have started the maven sync, so we have about 24 hours (for maven sync)
>> until I update these to the website and announce the release.
>> Thanks and regards,
>> Ishan
>>
>> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com> wrote:
>>>
>>> Sorry to hear that, make sure to take care of yourself first, the release
>>> can wait! I just backported to branch_6_6.
>>>
>>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya
>>> <ic...@gmail.com> a écrit :
>>>>
>>>> Hi Adrien,
>>>> Please proceed, by all means, to backport to release branch. I'm unwell
>>>> today, and I haven't been able to start the RC cutting today; planning to do
>>>> so after another 5-6 hours' rest.
>>>> Thanks,
>>>> Ishan
>>>>
>>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi Ishan,
>>>>>
>>>>> I don't think it is worth restarting RC build in case you already
>>>>> started, but in case you haven't started yet,
>>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to have in
>>>>> 6.6.
>>>>>
>>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya
>>>>> <ic...@gmail.com> a écrit :
>>>>>>
>>>>>> I attempted to build an RC, but failed repeatedly before realizing it
>>>>>> was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>>>>> I'm about to wrap up the day's work.
>>>>>>
>>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya
>>>>>> <ic...@gmail.com> wrote:
>>>>>>>
>>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>>>>>>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>>>>>>> know if someone has any objections.
>>>>>>>
>>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let
>>>>>>> me know if there's something that someone is working on which needs to get
>>>>>>> in before that.
>>>>>>>
>>>>>>> Thanks and regards,
>>>>>>> Ishan
>>>>>>>
>>>>>>>
>>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya
>>>>>>> <ic...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Sure Steve! Thanks!
>>>>>>>>
>>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Ishan,
>>>>>>>>>
>>>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>>>>> for 6.6?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Steve
>>>>>>>>> www.lucidworks.com
>>>>>>>>>
>>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi
>>>>>>>>> > <ji...@gmail.com> wrote:
>>>>>>>>> >
>>>>>>>>> > Ok thanks Ishan.
>>>>>>>>> >
>>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya"
>>>>>>>>> > <ic...@gmail.com> a écrit :
>>>>>>>>> > Sure, Jim. Please go ahead!
>>>>>>>>> >
>>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi
>>>>>>>>> > <ji...@gmail.com> wrote:
>>>>>>>>> > Hi,
>>>>>>>>> > Would be great to have
>>>>>>>>> > https://issues.apache.org/jira/browse/LUCENE-7824 included for 6.6. Can I
>>>>>>>>> > merge the fix this week end Ishan ?
>>>>>>>>> >
>>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya
>>>>>>>>> > <ic...@gmail.com>:
>>>>>>>>> > Done, Adrien. Thanks!
>>>>>>>>> >
>>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>>>>>>> > wrote:
>>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>>>>> > well? I think it would help realize that the 6.6 branch has been cut when
>>>>>>>>> > looking at the CHANGES.txt file and not forget about backporting?
>>>>>>>>> >
>>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya
>>>>>>>>> > <ic...@gmail.com> a écrit :
>>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to
>>>>>>>>> > add bugfixes to the branch, if needed.
>>>>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>>>>> > there are any objections.
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > Ishan
>>>>>>>>> >
>>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya
>>>>>>>>> > <ic...@gmail.com> wrote:
>>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>>>>> >
>>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty
>>>>>>>>> > <mg...@hotmail.com> wrote:
>>>>>>>>> > i was wondering if there was a specific test for
>>>>>>>>> > SpanPayloadCheckQuery method
>>>>>>>>> >
>>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>>>>> > SpanPayloadCheckQuery
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > I will submit JIRA with Patch
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>>>>> > sentence fragments (what we called phenomes) than current SEO
>>>>>>>>> > implementations
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Can you suggest a book to read to better understand Lucenes
>>>>>>>>> > pattern dissection and match algorithms?
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Many Thanks for helpful guidance
>>>>>>>>> > Martin
>>>>>>>>> > ______________________________________________
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>>>>> >
>>>>>>>>> > To: dev@lucene.apache.org
>>>>>>>>> > Subject: Re: Release 6.6
>>>>>>>>> >
>>>>>>>>> > Martin -
>>>>>>>>> >
>>>>>>>>> > I have to admit to still being unsure what the gist is here - is
>>>>>>>>> > there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>>>>> > Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>>>>> > now.
>>>>>>>>> >
>>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>>>>> > committed for 6.6.  If there is an issue to address with your work would you
>>>>>>>>> > please open a JIRA and include your patch there?
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > Erik
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>>>> >> wrote:
>>>>>>>>> >>
>>>>>>>>> >> Mornin' Erik
>>>>>>>>> >>
>>>>>>>>> >> there is a collectLeaf  override in
>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:
>>>>>>>>> >>
>>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>>>> >>     @Override
>>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int position,
>>>>>>>>> >> Term term) throws IOException {
>>>>>>>>> >>      ....
>>>>>>>>> >>      }
>>>>>>>>> >> }
>>>>>>>>> >>
>>>>>>>>> >> the modification in
>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf
>>>>>>>>> >> for query
>>>>>>>>> >>
>>>>>>>>> >> //initialise term
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>>>>> >> before term1=new org.apache.lucene.index.Term('field','withPayload')");
>>>>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>>>>> >> org.apache.lucene.index.Term("field", "withPayload");
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>>>>> >> term1="+term1);
>>>>>>>>> >>
>>>>>>>>> >> //assume position is 5
>>>>>>>>> >>     int position=5;
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >> 235 position="+position);
>>>>>>>>> >>
>>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >> 237 pay="+pay);
>>>>>>>>> >>
>>>>>>>>> >> //build spanQuery with term parameter
>>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>>>>> >> SpanTermQuery(term1);
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >> 239 spanQuery1="+spanQuery1);
>>>>>>>>> >>
>>>>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>>>>> >> payloadToMatch=new java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >> 241 payloadToMatch="+payloadToMatch);
>>>>>>>>> >>     payloadToMatch.add(pay);
>>>>>>>>> >>
>>>>>>>>> >> //build SpanPayloadCheckQuery
>>>>>>>>> >> query=new
>>>>>>>>> >> org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>>>>> >>
>>>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>>>>> >> query="+query);
>>>>>>>>> >>
>>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>>>>> >> directory with REAL test-data)
>>>>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>>>>> >> newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>>>>>>>> >>
>>>>>>>>> >> //build SegmentReader from Directory
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>>>>> >> ram="+ram);
>>>>>>>>> >> SegmentReader reader =
>>>>>>>>> >> getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>>>>> >> reader="+reader);
>>>>>>>>> >>
>>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>>>>> >> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >> 255 sr="+sr);
>>>>>>>>> >>
>>>>>>>>> >> //add term to SegmentReader postings
>>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>>>>>>>>> >> sr.postings(term1, PostingsEnum.PAYLOADS);
>>>>>>>>> >>
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>>>>> >> before
>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> >> postings="+postings);
>>>>>>>>> >>
>>>>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>>>>> >> before
>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> >> position="+position);
>>>>>>>>> >>
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>>>>> >> before
>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>>>>> >>     try
>>>>>>>>> >>     { //public void
>>>>>>>>> >> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>>>> >> //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>>>>> >>
>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>>> >> }
>>>>>>>>> >> catch(java.io.IOException ioe) {
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>>> >> IOException ="+ioe.getMessage()); }
>>>>>>>>> >>
>>>>>>>>> >> collectLeaf is the only method that compares
>>>>>>>>> >> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>>>> >> to determine "match"
>>>>>>>>> >>
>>>>>>>>> >> unless of course match between individual payload and
>>>>>>>>> >> payloadToMatch is tested elsewhere ?
>>>>>>>>> >>
>>>>>>>>> >> WDYT?
>>>>>>>>> >> Martin
>>>>>>>>> >> ______________________________________________
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>>>>> >> To: Lucene/Solr dev
>>>>>>>>> >> Subject: Re: Release 6.6
>>>>>>>>> >>
>>>>>>>>> >> Martin -
>>>>>>>>> >>
>>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out
>>>>>>>>> >> as it uses some logging and APIs that aren’t already in the project and
>>>>>>>>> >> classpath of these lucene tests within that queries module (within IntelliJ,
>>>>>>>>> >> mind you).
>>>>>>>>> >>
>>>>>>>>> >> I was able to resolve the misunderstanding (and
>>>>>>>>> >> .equals/.hashCode bugs) so everything is working as expected with
>>>>>>>>> >> SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or
>>>>>>>>> >> confirming that it is working properly at a lower level?
>>>>>>>>> >>
>>>>>>>>> >> Erik
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty
>>>>>>>>> >>> <mg...@hotmail.com> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>>>>>>> >>> click the link below.
>>>>>>>>> >>>
>>>>>>>>> >>> TestPayloadCheckQuery.java
>>>>>>>>> >>> attached
>>>>>>>>> >>>
>>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>>>>> >>>
>>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>>>>> >>> modification properly addresses your situation
>>>>>>>>> >>>
>>>>>>>>> >>> Thanks!
>>>>>>>>> >>> Martin
>>>>>>>>> >>> ______________________________________________
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>>>>> >>> To: dev@lucene.apache.org
>>>>>>>>> >>> Subject: Re: Release 6.6
>>>>>>>>> >>>
>>>>>>>>> >>> Martin - there is a test class specifically for this query.
>>>>>>>>> >>> See the recent commits I've made to test it further fixing .equals/.hashCode
>>>>>>>>> >>> and rewrite.
>>>>>>>>> >>>
>>>>>>>>> >>> Can you send your full test code?
>>>>>>>>> >>>
>>>>>>>>> >>>    Erik
>>>>>>>>> >>>
>>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>>>>>> >>> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to
>>>>>>>>> >>>> work I was about to reply just run that TestCase
>>>>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>>>>> >>>>
>>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>>>>> >>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>>>>> >>>>   @org.junit.Test
>>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>>>> >>>>
>>>>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>>>>> >>>> construct query
>>>>>>>>> >>>>
>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >>>> 257 before
>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> >>>> postings="+postings);
>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >>>> 258 before
>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> >>>> position="+position);
>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> >>>> 259 before
>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>>>>> >>>>
>>>>>>>>> >>>>     try
>>>>>>>>> >>>>     { //test public void
>>>>>>>>> >>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>>>> >>>> //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>>>>> >>>>
>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>>> >>>> }
>>>>>>>>> >>>> catch(java.io.IOException ioe) {
>>>>>>>>> >>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>>> >>>> IOException ="+ioe.getMessage()); }
>>>>>>>>> >>>>
>>>>>>>>> >>>> unless of course anyone has a better idea to test collectLeaf
>>>>>>>>> >>>> ?
>>>>>>>>> >>>> Martin
>>>>>>>>> >>>> ______________________________________________
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>>>>> >>>> To: dev@lucene.apache.org
>>>>>>>>> >>>> Subject: Re: Release 6.6
>>>>>>>>> >>>>
>>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>>>>>>>> >>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>>>>> >>>>
>>>>>>>>> >>>> Erik
>>>>>>>>> >>>>
>>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood
>>>>>>>>> >>>>> <wu...@wunderwood.org> wrote:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> wunder
>>>>>>>>> >>>>> Walter Underwood
>>>>>>>>> >>>>> wunder@wunderwood.org
>>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya
>>>>>>>>> >>>>>> <ic...@gmail.com> wrote:
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Hi,
>>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6.
>>>>>>>>> >>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>>>>> >>>>>> before 7.0 release).
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>>>>> >>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>>>>> >>>>>> issues.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> What do you think?
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Regards,
>>>>>>>>> >>>>>> Ishan
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

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


Re: Release 6.6

Posted by Mike Drob <md...@apache.org>.
Thanks for putting this together, Ishan!

On Mon, Jun 5, 2017 at 1:05 PM, Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> Hi all,
> I've updated the release notes here:
> https://wiki.apache.org/lucene-java/ReleaseNote66
> https://wiki.apache.org/solr/ReleaseNote66
>
> Please review / feel free to edit.
> I have started the maven sync, so we have about 24 hours (for maven sync)
> until I update these to the website and announce the release.
> Thanks and regards,
> Ishan
>
> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com> wrote:
>
>> Sorry to hear that, make sure to take care of yourself first, the release
>> can wait! I just backported to branch_6_6.
>>
>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> a écrit :
>>
>>> Hi Adrien,
>>> Please proceed, by all means, to backport to release branch. I'm unwell
>>> today, and I haven't been able to start the RC cutting today; planning to
>>> do so after another 5-6 hours' rest.
>>> Thanks,
>>> Ishan
>>>
>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
>>> wrote:
>>>
>>>> Hi Ishan,
>>>>
>>>> I don't think it is worth restarting RC build in case you already
>>>> started, but in case you haven't started yet,
>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to
>>>> have in 6.6.
>>>>
>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>
>>>>> I attempted to build an RC, but failed repeatedly before realizing it
>>>>> was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>>>> I'm about to wrap up the day's work.
>>>>>
>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>
>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>>>>>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>>>>>> know if someone has any objections.
>>>>>>
>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let
>>>>>> me know if there's something that someone is working on which needs to get
>>>>>> in before that.
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Ishan
>>>>>>
>>>>>>
>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>
>>>>>>> Sure Steve! Thanks!
>>>>>>>
>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ishan,
>>>>>>>>
>>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>>>> for 6.6?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Steve
>>>>>>>> www.lucidworks.com
>>>>>>>>
>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <
>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>> >
>>>>>>>> > Ok thanks Ishan.
>>>>>>>> >
>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>> > Sure, Jim. Please go ahead!
>>>>>>>> >
>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>> > Hi,
>>>>>>>> > Would be great to have https://issues.apache.org/jira
>>>>>>>> /browse/LUCENE-7824 included for 6.6. Can I merge the fix this
>>>>>>>> week end Ishan ?
>>>>>>>> >
>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com>:
>>>>>>>> > Done, Adrien. Thanks!
>>>>>>>> >
>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>>>> well? I think it would help realize that the 6.6 branch has been cut when
>>>>>>>> looking at the CHANGES.txt file and not forget about backporting?
>>>>>>>> >
>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to
>>>>>>>> add bugfixes to the branch, if needed.
>>>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>>>> there are any objections.
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > Ishan
>>>>>>>> >
>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>>>> >
>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <
>>>>>>>> mgainty@hotmail.com> wrote:
>>>>>>>> > i was wondering if there was a specific test for
>>>>>>>> SpanPayloadCheckQuery method
>>>>>>>> >
>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>>>> SpanPayloadCheckQuery
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > I will submit JIRA with Patch
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>>>> implementations
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Can you suggest a book to read to better understand Lucenes
>>>>>>>> pattern dissection and match algorithms?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Many Thanks for helpful guidance
>>>>>>>> > Martin
>>>>>>>> > ______________________________________________
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>>>> >
>>>>>>>> > To: dev@lucene.apache.org
>>>>>>>> > Subject: Re: Release 6.6
>>>>>>>> >
>>>>>>>> > Martin -
>>>>>>>> >
>>>>>>>> > I have to admit to still being unsure what the gist is here - is
>>>>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>>>> now.
>>>>>>>> >
>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>>>> committed for 6.6.  If there is an issue to address with your work would
>>>>>>>> you please open a JIRA and include your patch there?
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > Erik
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> Mornin' Erik
>>>>>>>> >>
>>>>>>>> >> there is a collectLeaf  override in
>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its
>>>>>>>> never called:
>>>>>>>> >>
>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>>> >>     @Override
>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int position,
>>>>>>>> Term term) throws IOException {
>>>>>>>> >>      ....
>>>>>>>> >>      }
>>>>>>>> >> }
>>>>>>>> >>
>>>>>>>> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>>>>>>>> tests collectLeaf for query
>>>>>>>> >>
>>>>>>>> >> //initialise term
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>>>> before term1=new org.apache.lucene.index.Term('
>>>>>>>> field','withPayload')");
>>>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>>>> term1="+term1);
>>>>>>>> >>
>>>>>>>> >> //assume position is 5
>>>>>>>> >>     int position=5;
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 235 position="+position);
>>>>>>>> >>
>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 237 pay="+pay);
>>>>>>>> >>
>>>>>>>> >> //build spanQuery with term parameter
>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>>>> SpanTermQuery(term1);
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 239 spanQuery1="+spanQuery1);
>>>>>>>> >>
>>>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>>>> payloadToMatch=new java.util.ArrayList<org.apache
>>>>>>>> .lucene.util.BytesRef>();
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 241 payloadToMatch="+payloadToMatch);
>>>>>>>> >>     payloadToMatch.add(pay);
>>>>>>>> >>
>>>>>>>> >> //build SpanPayloadCheckQuery
>>>>>>>> >> query=new org.apache.lucene.queries.payl
>>>>>>>> oads.SpanPayloadCheckQuery(
>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMa
>>>>>>>> tch);
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>>>> query="+query);
>>>>>>>> >>
>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>>>> directory with REAL test-data)
>>>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedCo
>>>>>>>> ntext.current().getRandom());
>>>>>>>> >>
>>>>>>>> >> //build SegmentReader from Directory
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>>>> ram="+ram);
>>>>>>>> >> SegmentReader reader = getOnlySegmentReader(org.apach
>>>>>>>> e.lucene.index.DirectoryReader.open(ram));
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>>>> reader="+reader);
>>>>>>>> >>
>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 255 sr="+sr);
>>>>>>>> >>
>>>>>>>> >> //add term to SegmentReader postings
>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>>>>>>>> sr.postings(term1, PostingsEnum.PAYLOADS);
>>>>>>>> >>
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> postings="+postings);
>>>>>>>> >>
>>>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> position="+position);
>>>>>>>> >>
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> term1="+term1);
>>>>>>>> >>     try
>>>>>>>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>>> postings, int position,       //org.apache.lucene.index.Term term)
>>>>>>>> throws java.io.IOException {
>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>> >> }
>>>>>>>> >> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>>> >>
>>>>>>>> >> collectLeaf is the only method that compares
>>>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>>> >> to determine "match"
>>>>>>>> >>
>>>>>>>> >> unless of course match between individual payload and
>>>>>>>> payloadToMatch is tested elsewhere ?
>>>>>>>> >>
>>>>>>>> >> WDYT?
>>>>>>>> >> Martin
>>>>>>>> >> ______________________________________________
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>>>> >> To: Lucene/Solr dev
>>>>>>>> >> Subject: Re: Release 6.6
>>>>>>>> >>
>>>>>>>> >> Martin -
>>>>>>>> >>
>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out
>>>>>>>> as it uses some logging and APIs that aren’t already in the project and
>>>>>>>> classpath of these lucene tests within that queries module (within
>>>>>>>> IntelliJ, mind you).
>>>>>>>> >>
>>>>>>>> >> I was able to resolve the misunderstanding (and
>>>>>>>> .equals/.hashCode bugs) so everything is working as expected with
>>>>>>>> SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or
>>>>>>>> confirming that it is working properly at a lower level?
>>>>>>>> >>
>>>>>>>> >> Erik
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>>> wrote:
>>>>>>>> >>>
>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>>>>>> click the link below.
>>>>>>>> >>>
>>>>>>>> >>> TestPayloadCheckQuery.java
>>>>>>>> >>> attached
>>>>>>>> >>>
>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>>>> >>>
>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>>>> modification properly addresses your situation
>>>>>>>> >>>
>>>>>>>> >>> Thanks!
>>>>>>>> >>> Martin
>>>>>>>> >>> ______________________________________________
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>>>> >>> To: dev@lucene.apache.org
>>>>>>>> >>> Subject: Re: Release 6.6
>>>>>>>> >>>
>>>>>>>> >>> Martin - there is a test class specifically for this query.
>>>>>>>>  See the recent commits I've made to test it further fixing
>>>>>>>> .equals/.hashCode and rewrite.
>>>>>>>> >>>
>>>>>>>> >>> Can you send your full test code?
>>>>>>>> >>>
>>>>>>>> >>>    Erik
>>>>>>>> >>>
>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>>>>> wrote:
>>>>>>>> >>>
>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to
>>>>>>>> work I was about to reply just run that TestCase
>>>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>>>> >>>>
>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>>>> >>>>   @org.junit.Test
>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>>> >>>>
>>>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>>>> construct query
>>>>>>>> >>>>
>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 257 before query.getPayloadChecker().coll
>>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> postings="+postings);
>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 258 before query.getPayloadChecker().coll
>>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> position="+position);
>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 259 before query.getPayloadChecker().coll
>>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> term1="+term1);
>>>>>>>> >>>>
>>>>>>>> >>>>     try
>>>>>>>> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>>> postings, int position,              //org.apache.lucene.index.Term term)
>>>>>>>> throws java.io.IOException {
>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>> >>>> }
>>>>>>>> >>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>>> >>>>
>>>>>>>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>>>>> >>>> Martin
>>>>>>>> >>>> ______________________________________________
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>>>> >>>> To: dev@lucene.apache.org
>>>>>>>> >>>> Subject: Re: Release 6.6
>>>>>>>> >>>>
>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>>>>>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>>>> >>>>
>>>>>>>> >>>> Erik
>>>>>>>> >>>>
>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>>>>>> wunder@wunderwood.org> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>>> >>>>>
>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>>> >>>>>
>>>>>>>> >>>>> wunder
>>>>>>>> >>>>> Walter Underwood
>>>>>>>> >>>>> wunder@wunderwood.org
>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> Hi,
>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6.
>>>>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>>>> before 7.0 release).
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>>>> issues.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> What do you think?
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> Regards,
>>>>>>>> >>>>>> Ishan
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Sure, Mikhail, we should. I am yet to finish up the post release steps and
planning to do so tomorrow.
Building backward compatibility indexes is also another important piece
from the post release steps that I'm yet to complete.
https://wiki.apache.org/lucene-java/ReleaseTodo#Post-Release

On Thu, Jun 8, 2017 at 3:01 AM, Mikhail Khludnev <mk...@apache.org> wrote:

> Thanks, Ishan.
> One question: shouldn't we close these
> https://issues.apache.org/jira/issues/?jql=(project%20%
> 3D%20SOLR%20OR%20project%20%3D%20LUCENE)%20AND%20status%
> 20%3D%20Resolved%20AND%20fixVersion%20%3D%206.6%
> 20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
> I can do that myself.
>
> On Wed, Jun 7, 2017 at 7:02 PM, Erick Erickson <er...@gmail.com>
> wrote:
>
>> Thanks Ishan!
>>
>> On Wed, Jun 7, 2017 at 4:06 AM, Ishan Chattopadhyaya
>> <ic...@gmail.com> wrote:
>> > Thanks for your help, Adrien!
>> >
>> > On Wed, Jun 7, 2017 at 1:04 PM, Adrien Grand <jp...@gmail.com> wrote:
>> >>
>> >> Thank you Ishan for doing this release!
>> >>
>> >> Le mar. 6 juin 2017 à 01:16, Michael McCandless
>> >> <lu...@mikemccandless.com> a écrit :
>> >>>
>> >>> Thank you Ishan.
>> >>>
>> >>> I reviewed the Lucene release notes and it looks great!
>> >>>
>> >>> Mike McCandless
>> >>>
>> >>> http://blog.mikemccandless.com
>> >>>
>> >>> On Mon, Jun 5, 2017 at 2:05 PM, Ishan Chattopadhyaya
>> >>> <ic...@gmail.com> wrote:
>> >>>>
>> >>>> Hi all,
>> >>>> I've updated the release notes here:
>> >>>> https://wiki.apache.org/lucene-java/ReleaseNote66
>> >>>> https://wiki.apache.org/solr/ReleaseNote66
>> >>>>
>> >>>> Please review / feel free to edit.
>> >>>> I have started the maven sync, so we have about 24 hours (for maven
>> >>>> sync) until I update these to the website and announce the release.
>> >>>> Thanks and regards,
>> >>>> Ishan
>> >>>>
>> >>>> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com>
>> wrote:
>> >>>>>
>> >>>>> Sorry to hear that, make sure to take care of yourself first, the
>> >>>>> release can wait! I just backported to branch_6_6.
>> >>>>>
>> >>>>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya
>> >>>>> <ic...@gmail.com> a écrit :
>> >>>>>>
>> >>>>>> Hi Adrien,
>> >>>>>> Please proceed, by all means, to backport to release branch. I'm
>> >>>>>> unwell today, and I haven't been able to start the RC cutting
>> today;
>> >>>>>> planning to do so after another 5-6 hours' rest.
>> >>>>>> Thanks,
>> >>>>>> Ishan
>> >>>>>>
>> >>>>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hi Ishan,
>> >>>>>>>
>> >>>>>>> I don't think it is worth restarting RC build in case you already
>> >>>>>>> started, but in case you haven't started yet,
>> >>>>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice
>> to have in
>> >>>>>>> 6.6.
>> >>>>>>>
>> >>>>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya
>> >>>>>>> <ic...@gmail.com> a écrit :
>> >>>>>>>>
>> >>>>>>>> I attempted to build an RC, but failed repeatedly before
>> realizing
>> >>>>>>>> it was due to, apart from test failures, LUCENE-7830 /
>> LUCENE-6438. I've
>> >>>>>>>> manually cleared up the dead symlinks now. I'll build the RC on
>> Tuesday, as
>> >>>>>>>> I'm about to wrap up the day's work.
>> >>>>>>>>
>> >>>>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya
>> >>>>>>>> <ic...@gmail.com> wrote:
>> >>>>>>>>>
>> >>>>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the
>> >>>>>>>>> release branch. It affects only the feature introduced in
>> SOLR-8440. Please
>> >>>>>>>>> let me know if someone has any objections.
>> >>>>>>>>>
>> >>>>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please
>> let
>> >>>>>>>>> me know if there's something that someone is working on which
>> needs to get
>> >>>>>>>>> in before that.
>> >>>>>>>>>
>> >>>>>>>>> Thanks and regards,
>> >>>>>>>>> Ishan
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya
>> >>>>>>>>> <ic...@gmail.com> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Sure Steve! Thanks!
>> >>>>>>>>>>
>> >>>>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> Ishan,
>> >>>>>>>>>>>
>> >>>>>>>>>>> Okay to include https://issues.apache.org/jira
>> /browse/LUCENE-7821
>> >>>>>>>>>>> for 6.6?
>> >>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Steve
>> >>>>>>>>>>> www.lucidworks.com
>> >>>>>>>>>>>
>> >>>>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi
>> >>>>>>>>>>> > <ji...@gmail.com> wrote:
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Ok thanks Ishan.
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya"
>> >>>>>>>>>>> > <ic...@gmail.com> a écrit :
>> >>>>>>>>>>> > Sure, Jim. Please go ahead!
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi
>> >>>>>>>>>>> > <ji...@gmail.com> wrote:
>> >>>>>>>>>>> > Hi,
>> >>>>>>>>>>> > Would be great to have
>> >>>>>>>>>>> > https://issues.apache.org/jira/browse/LUCENE-7824 included
>> for 6.6. Can I
>> >>>>>>>>>>> > merge the fix this week end Ishan ?
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya
>> >>>>>>>>>>> > <ic...@gmail.com>:
>> >>>>>>>>>>> > Done, Adrien. Thanks!
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand
>> >>>>>>>>>>> > <jp...@gmail.com> wrote:
>> >>>>>>>>>>> > Ishan, wdyt about running addVersion on the
>> branch_6x/master as
>> >>>>>>>>>>> > well? I think it would help realize that the 6.6 branch has
>> been cut when
>> >>>>>>>>>>> > looking at the CHANGES.txt file and not forget about
>> backporting?
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya
>> >>>>>>>>>>> > <ic...@gmail.com> a écrit :
>> >>>>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free
>> to
>> >>>>>>>>>>> > add bugfixes to the branch, if needed.
>> >>>>>>>>>>> > Planning to build the first RC on 15 May. Please let me
>> know if
>> >>>>>>>>>>> > there are any objections.
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Thanks,
>> >>>>>>>>>>> > Ishan
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya
>> >>>>>>>>>>> > <ic...@gmail.com> wrote:
>> >>>>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty
>> >>>>>>>>>>> > <mg...@hotmail.com> wrote:
>> >>>>>>>>>>> > i was wondering if there was a specific test for
>> >>>>>>>>>>> > SpanPayloadCheckQuery method
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > the only implementation i could locate was in collectLeaf of
>> >>>>>>>>>>> > SpanPayloadCheckQuery
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > I will submit JIRA with Patch
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for
>> dissecting
>> >>>>>>>>>>> > sentence fragments (what we called phenomes) than current
>> SEO
>> >>>>>>>>>>> > implementations
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Can you suggest a book to read to better understand Lucenes
>> >>>>>>>>>>> > pattern dissection and match algorithms?
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Many Thanks for helpful guidance
>> >>>>>>>>>>> > Martin
>> >>>>>>>>>>> > ______________________________________________
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>> >>>>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > To: dev@lucene.apache.org
>> >>>>>>>>>>> > Subject: Re: Release 6.6
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Martin -
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > I have to admit to still being unsure what the gist is here
>> -
>> >>>>>>>>>>> > is there a bug?   Apologies for not catching what you’re
>> saying/showing
>> >>>>>>>>>>> > here.  Again, as far as I can tell SpanPayloadCheckQuery is
>> working as
>> >>>>>>>>>>> > expected now.
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>> >>>>>>>>>>> > committed for 6.6.  If there is an issue to address with
>> your work would you
>> >>>>>>>>>>> > please open a JIRA and include your patch there?
>> >>>>>>>>>>> >
>> >>>>>>>>>>> > Thanks,
>> >>>>>>>>>>> > Erik
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty
>> >>>>>>>>>>> >> <mg...@hotmail.com> wrote:
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> Mornin' Erik
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> there is a collectLeaf  override in
>> >>>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadSpans ..but
>> its never called:
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>> >>>>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>> >>>>>>>>>>> >>     @Override
>> >>>>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int
>> >>>>>>>>>>> >> position, Term term) throws IOException {
>> >>>>>>>>>>> >>      ....
>> >>>>>>>>>>> >>      }
>> >>>>>>>>>>> >> }
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> the modification in
>> >>>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>> tests collectLeaf
>> >>>>>>>>>>> >> for query
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //initialise term
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 231 before term1=new org.apache.lucene.index.Term('
>> field','withPayload')");
>> >>>>>>>>>>> >> org.apache.lucene.index.Term term1=new
>> >>>>>>>>>>> >> org.apache.lucene.index.Term("field", "withPayload");
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 233 term1="+term1);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //assume position is 5
>> >>>>>>>>>>> >>     int position=5;
>> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> >>>>>>>>>>> >> LINE 235 position="+position);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> >>>>>>>>>>> >> LINE 237 pay="+pay);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //build spanQuery with term parameter
>> >>>>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 =
>> new
>> >>>>>>>>>>> >> SpanTermQuery(term1);
>> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> >>>>>>>>>>> >> LINE 239 spanQuery1="+spanQuery1);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //add BytesRef to payloadToMatch list
>> >>>>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>> >>>>>>>>>>> >> payloadToMatch=new java.util.ArrayList<org.apache
>> .lucene.util.BytesRef>();
>> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> >>>>>>>>>>> >> LINE 241 payloadToMatch="+payloadToMatch);
>> >>>>>>>>>>> >>     payloadToMatch.add(pay);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //build SpanPayloadCheckQuery
>> >>>>>>>>>>> >> query=new
>> >>>>>>>>>>> >> org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>> >>>>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> (java.util.List<org.apache.luc
>> ene.util.BytesRef>)payloadToMatch);
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 249 query="+query);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>> >>>>>>>>>>> >> directory with REAL test-data)
>> >>>>>>>>>>> >> org.apache.lucene.store.Directory ram =
>> >>>>>>>>>>> >> newDirectory(com.carrotsearch.
>> randomizedtesting.RandomizedContext.current().getRandom());
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //build SegmentReader from Directory
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 251 ram="+ram);
>> >>>>>>>>>>> >> SegmentReader reader =
>> >>>>>>>>>>> >> getOnlySegmentReader(org.apach
>> e.lucene.index.DirectoryReader.open(ram));
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 253 reader="+reader);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>> >>>>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>> >>>>>>>>>>> >> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(
>> reader);
>> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> >>>>>>>>>>> >> LINE 255 sr="+sr);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //add term to SegmentReader postings
>> >>>>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>> >>>>>>>>>>> >> sr.postings(term1, PostingsEnum.PAYLOADS);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 257 before
>> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.
>> index.PostingsEnum)postings,
>> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
>> >>>>>>>>>>> >> postings="+postings);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> //display the parameters for collectLeaf method for query:
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 258 before
>> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.
>> index.PostingsEnum)postings,
>> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
>> >>>>>>>>>>> >> position="+position);
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >> 259 before
>> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.
>> index.PostingsEnum)postings,
>> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
>> term1="+term1);
>> >>>>>>>>>>> >>     try
>> >>>>>>>>>>> >>     { //public void
>> >>>>>>>>>>> >> collectLeaf(org.apache.lucene.index.PostingsEnum
>> postings, int position,
>> >>>>>>>>>>> >> //org.apache.lucene.index.Term term) throws
>> java.io.IOException {
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.
>> index.PostingsEnum)postings,
>> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1);
>> >>>>>>>>>>> >> }
>> >>>>>>>>>>> >> catch(java.io.IOException ioe) {
>> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE 264
>> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.
>> index.PostingsEnum)postings,
>> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) LINE
>> 106 throws
>> >>>>>>>>>>> >> IOException ="+ioe.getMessage()); }
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> collectLeaf is the only method that compares
>> >>>>>>>>>>> >> matches=payloadToMatch.get(upto).bytesEquals(payload)
>> >>>>>>>>>>> >> to determine "match"
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> unless of course match between individual payload and
>> >>>>>>>>>>> >> payloadToMatch is tested elsewhere ?
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> WDYT?
>> >>>>>>>>>>> >> Martin
>> >>>>>>>>>>> >> ______________________________________________
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>> >>>>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>> >>>>>>>>>>> >> To: Lucene/Solr dev
>> >>>>>>>>>>> >> Subject: Re: Release 6.6
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> Martin -
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it
>> out
>> >>>>>>>>>>> >> as it uses some logging and APIs that aren’t already in
>> the project and
>> >>>>>>>>>>> >> classpath of these lucene tests within that queries module
>> (within IntelliJ,
>> >>>>>>>>>>> >> mind you).
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> I was able to resolve the misunderstanding (and
>> >>>>>>>>>>> >> .equals/.hashCode bugs) so everything is working as
>> expected with
>> >>>>>>>>>>> >> SpanPayloadCheckQuery for me now.   Do your tests point
>> out an issue?   Or
>> >>>>>>>>>>> >> confirming that it is working properly at a lower level?
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >> Erik
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >>
>> >>>>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty
>> >>>>>>>>>>> >>> <mg...@hotmail.com> wrote:
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view
>> >>>>>>>>>>> >>> it, click the link below.
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> TestPayloadCheckQuery.java
>> >>>>>>>>>>> >>> attached
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>> >>>>>>>>>>> >>> modification properly addresses your situation
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> Thanks!
>> >>>>>>>>>>> >>> Martin
>> >>>>>>>>>>> >>> ______________________________________________
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>> >>>>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>> >>>>>>>>>>> >>> To: dev@lucene.apache.org
>> >>>>>>>>>>> >>> Subject: Re: Release 6.6
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> Martin - there is a test class specifically for this
>> query.
>> >>>>>>>>>>> >>> See the recent commits I've made to test it further
>> fixing .equals/.hashCode
>> >>>>>>>>>>> >>> and rewrite.
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> Can you send your full test code?
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>>    Erik
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty
>> >>>>>>>>>>> >>> <mg...@hotmail.com> wrote:
>> >>>>>>>>>>> >>>
>> >>>>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery
>> to
>> >>>>>>>>>>> >>>> work I was about to reply just run that TestCase
>> >>>>>>>>>>> >>>> (until i discovered there wasnt any!)
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>> >>>>>>>>>>> >>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>> mod:
>> >>>>>>>>>>> >>>>   @org.junit.Test
>> >>>>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>>     //now lets test the collectLeaf for query
>> >>>>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery
>> to
>> >>>>>>>>>>> >>>> construct query
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >>>> 257 before
>> >>>>>>>>>>> >>>> query.getPayloadChecker().coll
>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
>> >>>>>>>>>>> >>>> postings="+postings);
>> >>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >>>> 258 before
>> >>>>>>>>>>> >>>> query.getPayloadChecker().coll
>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
>> >>>>>>>>>>> >>>> position="+position);
>> >>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE
>> >>>>>>>>>>> >>>> 259 before
>> >>>>>>>>>>> >>>> query.getPayloadChecker().coll
>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1)
>> where term1="+term1);
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>>     try
>> >>>>>>>>>>> >>>>     { //test public void
>> >>>>>>>>>>> >>>> collectLeaf(org.apache.lucene.index.PostingsEnum
>> postings, int position,
>> >>>>>>>>>>> >>>> //org.apache.lucene.index.Term term) throws
>> java.io.IOException {
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>> query.getPayloadChecker().coll
>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1);
>> >>>>>>>>>>> >>>> }
>> >>>>>>>>>>> >>>> catch(java.io.IOException ioe) {
>> >>>>>>>>>>> >>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE 264
>> >>>>>>>>>>> >>>> query.getPayloadChecker().coll
>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) LINE
>> 106 throws
>> >>>>>>>>>>> >>>> IOException ="+ioe.getMessage()); }
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>> unless of course anyone has a better idea to test
>> >>>>>>>>>>> >>>> collectLeaf ?
>> >>>>>>>>>>> >>>> Martin
>> >>>>>>>>>>> >>>> ______________________________________________
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>> >>>>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>> >>>>>>>>>>> >>>> To: dev@lucene.apache.org
>> >>>>>>>>>>> >>>> Subject: Re: Release 6.6
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a
>> >>>>>>>>>>> >>>> good start (or will the 2.5 year old patch still apply
>> and be acceptable
>> >>>>>>>>>>> >>>> as-is?)
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>> Erik
>> >>>>>>>>>>> >>>>
>> >>>>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood
>> >>>>>>>>>>> >>>>> <wu...@wunderwood.org> wrote:
>> >>>>>>>>>>> >>>>>
>> >>>>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>> >>>>>>>>>>> >>>>>
>> >>>>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>> >>>>>>>>>>> >>>>>
>> >>>>>>>>>>> >>>>> wunder
>> >>>>>>>>>>> >>>>> Walter Underwood
>> >>>>>>>>>>> >>>>> wunder@wunderwood.org
>> >>>>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>> >>>>>>>>>>> >>>>>
>> >>>>>>>>>>> >>>>>
>> >>>>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya
>> >>>>>>>>>>> >>>>>> <ic...@gmail.com> wrote:
>> >>>>>>>>>>> >>>>>>
>> >>>>>>>>>>> >>>>>> Hi,
>> >>>>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for
>> 6.6.
>> >>>>>>>>>>> >>>>>> I'd like to propose a 6.6 release (perhaps the last 6x
>> non-bug-fix release
>> >>>>>>>>>>> >>>>>> before 7.0 release).
>> >>>>>>>>>>> >>>>>>
>> >>>>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the
>> release
>> >>>>>>>>>>> >>>>>> branch around 4th May, in order to let some time for
>> devs to finish current
>> >>>>>>>>>>> >>>>>> issues.
>> >>>>>>>>>>> >>>>>>
>> >>>>>>>>>>> >>>>>> What do you think?
>> >>>>>>>>>>> >>>>>>
>> >>>>>>>>>>> >>>>>> Regards,
>> >>>>>>>>>>> >>>>>> Ishan
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>> >
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> ------------------------------------------------------------
>> ---------
>> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>
>> >>>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

Re: Release 6.6

Posted by Mikhail Khludnev <mk...@apache.org>.
Thanks, Ishan.
One question: shouldn't we close these
https://issues.apache.org/jira/issues/?jql=(project%20%3D%20SOLR%20OR%20project%20%3D%20LUCENE)%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20%3D%206.6%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
I can do that myself.

On Wed, Jun 7, 2017 at 7:02 PM, Erick Erickson <er...@gmail.com>
wrote:

> Thanks Ishan!
>
> On Wed, Jun 7, 2017 at 4:06 AM, Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
> > Thanks for your help, Adrien!
> >
> > On Wed, Jun 7, 2017 at 1:04 PM, Adrien Grand <jp...@gmail.com> wrote:
> >>
> >> Thank you Ishan for doing this release!
> >>
> >> Le mar. 6 juin 2017 à 01:16, Michael McCandless
> >> <lu...@mikemccandless.com> a écrit :
> >>>
> >>> Thank you Ishan.
> >>>
> >>> I reviewed the Lucene release notes and it looks great!
> >>>
> >>> Mike McCandless
> >>>
> >>> http://blog.mikemccandless.com
> >>>
> >>> On Mon, Jun 5, 2017 at 2:05 PM, Ishan Chattopadhyaya
> >>> <ic...@gmail.com> wrote:
> >>>>
> >>>> Hi all,
> >>>> I've updated the release notes here:
> >>>> https://wiki.apache.org/lucene-java/ReleaseNote66
> >>>> https://wiki.apache.org/solr/ReleaseNote66
> >>>>
> >>>> Please review / feel free to edit.
> >>>> I have started the maven sync, so we have about 24 hours (for maven
> >>>> sync) until I update these to the website and announce the release.
> >>>> Thanks and regards,
> >>>> Ishan
> >>>>
> >>>> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com>
> wrote:
> >>>>>
> >>>>> Sorry to hear that, make sure to take care of yourself first, the
> >>>>> release can wait! I just backported to branch_6_6.
> >>>>>
> >>>>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya
> >>>>> <ic...@gmail.com> a écrit :
> >>>>>>
> >>>>>> Hi Adrien,
> >>>>>> Please proceed, by all means, to backport to release branch. I'm
> >>>>>> unwell today, and I haven't been able to start the RC cutting today;
> >>>>>> planning to do so after another 5-6 hours' rest.
> >>>>>> Thanks,
> >>>>>> Ishan
> >>>>>>
> >>>>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hi Ishan,
> >>>>>>>
> >>>>>>> I don't think it is worth restarting RC build in case you already
> >>>>>>> started, but in case you haven't started yet,
> >>>>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice
> to have in
> >>>>>>> 6.6.
> >>>>>>>
> >>>>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya
> >>>>>>> <ic...@gmail.com> a écrit :
> >>>>>>>>
> >>>>>>>> I attempted to build an RC, but failed repeatedly before realizing
> >>>>>>>> it was due to, apart from test failures, LUCENE-7830 /
> LUCENE-6438. I've
> >>>>>>>> manually cleared up the dead symlinks now. I'll build the RC on
> Tuesday, as
> >>>>>>>> I'm about to wrap up the day's work.
> >>>>>>>>
> >>>>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya
> >>>>>>>> <ic...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the
> >>>>>>>>> release branch. It affects only the feature introduced in
> SOLR-8440. Please
> >>>>>>>>> let me know if someone has any objections.
> >>>>>>>>>
> >>>>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please
> let
> >>>>>>>>> me know if there's something that someone is working on which
> needs to get
> >>>>>>>>> in before that.
> >>>>>>>>>
> >>>>>>>>> Thanks and regards,
> >>>>>>>>> Ishan
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya
> >>>>>>>>> <ic...@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Sure Steve! Thanks!
> >>>>>>>>>>
> >>>>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Ishan,
> >>>>>>>>>>>
> >>>>>>>>>>> Okay to include https://issues.apache.org/
> jira/browse/LUCENE-7821
> >>>>>>>>>>> for 6.6?
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Steve
> >>>>>>>>>>> www.lucidworks.com
> >>>>>>>>>>>
> >>>>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi
> >>>>>>>>>>> > <ji...@gmail.com> wrote:
> >>>>>>>>>>> >
> >>>>>>>>>>> > Ok thanks Ishan.
> >>>>>>>>>>> >
> >>>>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya"
> >>>>>>>>>>> > <ic...@gmail.com> a écrit :
> >>>>>>>>>>> > Sure, Jim. Please go ahead!
> >>>>>>>>>>> >
> >>>>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi
> >>>>>>>>>>> > <ji...@gmail.com> wrote:
> >>>>>>>>>>> > Hi,
> >>>>>>>>>>> > Would be great to have
> >>>>>>>>>>> > https://issues.apache.org/jira/browse/LUCENE-7824 included
> for 6.6. Can I
> >>>>>>>>>>> > merge the fix this week end Ishan ?
> >>>>>>>>>>> >
> >>>>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya
> >>>>>>>>>>> > <ic...@gmail.com>:
> >>>>>>>>>>> > Done, Adrien. Thanks!
> >>>>>>>>>>> >
> >>>>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand
> >>>>>>>>>>> > <jp...@gmail.com> wrote:
> >>>>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master
> as
> >>>>>>>>>>> > well? I think it would help realize that the 6.6 branch has
> been cut when
> >>>>>>>>>>> > looking at the CHANGES.txt file and not forget about
> backporting?
> >>>>>>>>>>> >
> >>>>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya
> >>>>>>>>>>> > <ic...@gmail.com> a écrit :
> >>>>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free
> to
> >>>>>>>>>>> > add bugfixes to the branch, if needed.
> >>>>>>>>>>> > Planning to build the first RC on 15 May. Please let me know
> if
> >>>>>>>>>>> > there are any objections.
> >>>>>>>>>>> >
> >>>>>>>>>>> > Thanks,
> >>>>>>>>>>> > Ishan
> >>>>>>>>>>> >
> >>>>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya
> >>>>>>>>>>> > <ic...@gmail.com> wrote:
> >>>>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
> >>>>>>>>>>> >
> >>>>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty
> >>>>>>>>>>> > <mg...@hotmail.com> wrote:
> >>>>>>>>>>> > i was wondering if there was a specific test for
> >>>>>>>>>>> > SpanPayloadCheckQuery method
> >>>>>>>>>>> >
> >>>>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> > the only implementation i could locate was in collectLeaf of
> >>>>>>>>>>> > SpanPayloadCheckQuery
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> > I will submit JIRA with Patch
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for
> dissecting
> >>>>>>>>>>> > sentence fragments (what we called phenomes) than current SEO
> >>>>>>>>>>> > implementations
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> > Can you suggest a book to read to better understand Lucenes
> >>>>>>>>>>> > pattern dissection and match algorithms?
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> > Many Thanks for helpful guidance
> >>>>>>>>>>> > Martin
> >>>>>>>>>>> > ______________________________________________
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
> >>>>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
> >>>>>>>>>>> >
> >>>>>>>>>>> > To: dev@lucene.apache.org
> >>>>>>>>>>> > Subject: Re: Release 6.6
> >>>>>>>>>>> >
> >>>>>>>>>>> > Martin -
> >>>>>>>>>>> >
> >>>>>>>>>>> > I have to admit to still being unsure what the gist is here -
> >>>>>>>>>>> > is there a bug?   Apologies for not catching what you’re
> saying/showing
> >>>>>>>>>>> > here.  Again, as far as I can tell SpanPayloadCheckQuery is
> working as
> >>>>>>>>>>> > expected now.
> >>>>>>>>>>> >
> >>>>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
> >>>>>>>>>>> > committed for 6.6.  If there is an issue to address with
> your work would you
> >>>>>>>>>>> > please open a JIRA and include your patch there?
> >>>>>>>>>>> >
> >>>>>>>>>>> > Thanks,
> >>>>>>>>>>> > Erik
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty
> >>>>>>>>>>> >> <mg...@hotmail.com> wrote:
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> Mornin' Erik
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> there is a collectLeaf  override in
> >>>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadSpans ..but
> its never called:
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
> >>>>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
> >>>>>>>>>>> >>     @Override
> >>>>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int
> >>>>>>>>>>> >> position, Term term) throws IOException {
> >>>>>>>>>>> >>      ....
> >>>>>>>>>>> >>      }
> >>>>>>>>>>> >> }
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> the modification in
> >>>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadCheckQuery
> tests collectLeaf
> >>>>>>>>>>> >> for query
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //initialise term
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 231 before term1=new org.apache.lucene.index.Term('
> field','withPayload')");
> >>>>>>>>>>> >> org.apache.lucene.index.Term term1=new
> >>>>>>>>>>> >> org.apache.lucene.index.Term("field", "withPayload");
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 233 term1="+term1);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //assume position is 5
> >>>>>>>>>>> >>     int position=5;
> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> >>>>>>>>>>> >> LINE 235 position="+position);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> >>>>>>>>>>> >> LINE 237 pay="+pay);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //build spanQuery with term parameter
> >>>>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 =
> new
> >>>>>>>>>>> >> SpanTermQuery(term1);
> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> >>>>>>>>>>> >> LINE 239 spanQuery1="+spanQuery1);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //add BytesRef to payloadToMatch list
> >>>>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
> >>>>>>>>>>> >> payloadToMatch=new java.util.ArrayList<org.
> apache.lucene.util.BytesRef>();
> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> >>>>>>>>>>> >> LINE 241 payloadToMatch="+payloadToMatch);
> >>>>>>>>>>> >>     payloadToMatch.add(pay);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //build SpanPayloadCheckQuery
> >>>>>>>>>>> >> query=new
> >>>>>>>>>>> >> org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
> >>>>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)
> payloadToMatch);
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 249 query="+query);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
> >>>>>>>>>>> >> directory with REAL test-data)
> >>>>>>>>>>> >> org.apache.lucene.store.Directory ram =
> >>>>>>>>>>> >> newDirectory(com.carrotsearch.randomizedtesting.
> RandomizedContext.current().getRandom());
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //build SegmentReader from Directory
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 251 ram="+ram);
> >>>>>>>>>>> >> SegmentReader reader =
> >>>>>>>>>>> >> getOnlySegmentReader(org.apache.lucene.index.
> DirectoryReader.open(ram));
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 253 reader="+reader);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
> >>>>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
> >>>>>>>>>>> >> org.apache.lucene.index.SlowCompositeReaderWrapper.
> wrap(reader);
> >>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> >>>>>>>>>>> >> LINE 255 sr="+sr);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //add term to SegmentReader postings
> >>>>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
> >>>>>>>>>>> >> sr.postings(term1, PostingsEnum.PAYLOADS);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 257 before
> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
> >>>>>>>>>>> >> postings="+postings);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> //display the parameters for collectLeaf method for query:
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 258 before
> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
> >>>>>>>>>>> >> position="+position);
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
> >>>>>>>>>>> >> 259 before
> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
> term1="+term1);
> >>>>>>>>>>> >>     try
> >>>>>>>>>>> >>     { //public void
> >>>>>>>>>>> >> collectLeaf(org.apache.lucene.index.PostingsEnum postings,
> int position,
> >>>>>>>>>>> >> //org.apache.lucene.index.Term term) throws
> java.io.IOException {
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1);
> >>>>>>>>>>> >> }
> >>>>>>>>>>> >> catch(java.io.IOException ioe) {
> >>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE 264
> >>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) LINE
> 106 throws
> >>>>>>>>>>> >> IOException ="+ioe.getMessage()); }
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> collectLeaf is the only method that compares
> >>>>>>>>>>> >> matches=payloadToMatch.get(upto).bytesEquals(payload)
> >>>>>>>>>>> >> to determine "match"
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> unless of course match between individual payload and
> >>>>>>>>>>> >> payloadToMatch is tested elsewhere ?
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> WDYT?
> >>>>>>>>>>> >> Martin
> >>>>>>>>>>> >> ______________________________________________
> >>>>>>>>>>> >>
> >>>>>>>>>>> >>
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
> >>>>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
> >>>>>>>>>>> >> To: Lucene/Solr dev
> >>>>>>>>>>> >> Subject: Re: Release 6.6
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> Martin -
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it
> out
> >>>>>>>>>>> >> as it uses some logging and APIs that aren’t already in the
> project and
> >>>>>>>>>>> >> classpath of these lucene tests within that queries module
> (within IntelliJ,
> >>>>>>>>>>> >> mind you).
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> I was able to resolve the misunderstanding (and
> >>>>>>>>>>> >> .equals/.hashCode bugs) so everything is working as
> expected with
> >>>>>>>>>>> >> SpanPayloadCheckQuery for me now.   Do your tests point out
> an issue?   Or
> >>>>>>>>>>> >> confirming that it is working properly at a lower level?
> >>>>>>>>>>> >>
> >>>>>>>>>>> >> Erik
> >>>>>>>>>>> >>
> >>>>>>>>>>> >>
> >>>>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty
> >>>>>>>>>>> >>> <mg...@hotmail.com> wrote:
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view
> >>>>>>>>>>> >>> it, click the link below.
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> TestPayloadCheckQuery.java
> >>>>>>>>>>> >>> attached
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
> >>>>>>>>>>> >>> modification properly addresses your situation
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> Thanks!
> >>>>>>>>>>> >>> Martin
> >>>>>>>>>>> >>> ______________________________________________
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
> >>>>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
> >>>>>>>>>>> >>> To: dev@lucene.apache.org
> >>>>>>>>>>> >>> Subject: Re: Release 6.6
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> Martin - there is a test class specifically for this query.
> >>>>>>>>>>> >>> See the recent commits I've made to test it further fixing
> .equals/.hashCode
> >>>>>>>>>>> >>> and rewrite.
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> Can you send your full test code?
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>>    Erik
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty
> >>>>>>>>>>> >>> <mg...@hotmail.com> wrote:
> >>>>>>>>>>> >>>
> >>>>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery
> to
> >>>>>>>>>>> >>>> work I was about to reply just run that TestCase
> >>>>>>>>>>> >>>> (until i discovered there wasnt any!)
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
> >>>>>>>>>>> >>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery
> mod:
> >>>>>>>>>>> >>>>   @org.junit.Test
> >>>>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>>     //now lets test the collectLeaf for query
> >>>>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery
> to
> >>>>>>>>>>> >>>> construct query
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE
> >>>>>>>>>>> >>>> 257 before
> >>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
> >>>>>>>>>>> >>>> postings="+postings);
> >>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE
> >>>>>>>>>>> >>>> 258 before
> >>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
> >>>>>>>>>>> >>>> position="+position);
> >>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE
> >>>>>>>>>>> >>>> 259 before
> >>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
> term1="+term1);
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>>     try
> >>>>>>>>>>> >>>>     { //test public void
> >>>>>>>>>>> >>>> collectLeaf(org.apache.lucene.index.PostingsEnum
> postings, int position,
> >>>>>>>>>>> >>>> //org.apache.lucene.index.Term term) throws
> java.io.IOException {
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1);
> >>>>>>>>>>> >>>> }
> >>>>>>>>>>> >>>> catch(java.io.IOException ioe) {
> >>>>>>>>>>> >>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE 264
> >>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings,
> >>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) LINE
> 106 throws
> >>>>>>>>>>> >>>> IOException ="+ioe.getMessage()); }
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>> unless of course anyone has a better idea to test
> >>>>>>>>>>> >>>> collectLeaf ?
> >>>>>>>>>>> >>>> Martin
> >>>>>>>>>>> >>>> ______________________________________________
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
> >>>>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
> >>>>>>>>>>> >>>> To: dev@lucene.apache.org
> >>>>>>>>>>> >>>> Subject: Re: Release 6.6
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a
> >>>>>>>>>>> >>>> good start (or will the 2.5 year old patch still apply
> and be acceptable
> >>>>>>>>>>> >>>> as-is?)
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>> Erik
> >>>>>>>>>>> >>>>
> >>>>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood
> >>>>>>>>>>> >>>>> <wu...@wunderwood.org> wrote:
> >>>>>>>>>>> >>>>>
> >>>>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
> >>>>>>>>>>> >>>>>
> >>>>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
> >>>>>>>>>>> >>>>>
> >>>>>>>>>>> >>>>> wunder
> >>>>>>>>>>> >>>>> Walter Underwood
> >>>>>>>>>>> >>>>> wunder@wunderwood.org
> >>>>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
> >>>>>>>>>>> >>>>>
> >>>>>>>>>>> >>>>>
> >>>>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya
> >>>>>>>>>>> >>>>>> <ic...@gmail.com> wrote:
> >>>>>>>>>>> >>>>>>
> >>>>>>>>>>> >>>>>> Hi,
> >>>>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for
> 6.6.
> >>>>>>>>>>> >>>>>> I'd like to propose a 6.6 release (perhaps the last 6x
> non-bug-fix release
> >>>>>>>>>>> >>>>>> before 7.0 release).
> >>>>>>>>>>> >>>>>>
> >>>>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the
> release
> >>>>>>>>>>> >>>>>> branch around 4th May, in order to let some time for
> devs to finish current
> >>>>>>>>>>> >>>>>> issues.
> >>>>>>>>>>> >>>>>>
> >>>>>>>>>>> >>>>>> What do you think?
> >>>>>>>>>>> >>>>>>
> >>>>>>>>>>> >>>>>> Regards,
> >>>>>>>>>>> >>>>>> Ishan
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>> >
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> ------------------------------------------------------------
> ---------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>


-- 
Sincerely yours
Mikhail Khludnev

Re: Release 6.6

Posted by Erick Erickson <er...@gmail.com>.
Thanks Ishan!

On Wed, Jun 7, 2017 at 4:06 AM, Ishan Chattopadhyaya
<ic...@gmail.com> wrote:
> Thanks for your help, Adrien!
>
> On Wed, Jun 7, 2017 at 1:04 PM, Adrien Grand <jp...@gmail.com> wrote:
>>
>> Thank you Ishan for doing this release!
>>
>> Le mar. 6 juin 2017 à 01:16, Michael McCandless
>> <lu...@mikemccandless.com> a écrit :
>>>
>>> Thank you Ishan.
>>>
>>> I reviewed the Lucene release notes and it looks great!
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Mon, Jun 5, 2017 at 2:05 PM, Ishan Chattopadhyaya
>>> <ic...@gmail.com> wrote:
>>>>
>>>> Hi all,
>>>> I've updated the release notes here:
>>>> https://wiki.apache.org/lucene-java/ReleaseNote66
>>>> https://wiki.apache.org/solr/ReleaseNote66
>>>>
>>>> Please review / feel free to edit.
>>>> I have started the maven sync, so we have about 24 hours (for maven
>>>> sync) until I update these to the website and announce the release.
>>>> Thanks and regards,
>>>> Ishan
>>>>
>>>> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com> wrote:
>>>>>
>>>>> Sorry to hear that, make sure to take care of yourself first, the
>>>>> release can wait! I just backported to branch_6_6.
>>>>>
>>>>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya
>>>>> <ic...@gmail.com> a écrit :
>>>>>>
>>>>>> Hi Adrien,
>>>>>> Please proceed, by all means, to backport to release branch. I'm
>>>>>> unwell today, and I haven't been able to start the RC cutting today;
>>>>>> planning to do so after another 5-6 hours' rest.
>>>>>> Thanks,
>>>>>> Ishan
>>>>>>
>>>>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Ishan,
>>>>>>>
>>>>>>> I don't think it is worth restarting RC build in case you already
>>>>>>> started, but in case you haven't started yet,
>>>>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to have in
>>>>>>> 6.6.
>>>>>>>
>>>>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya
>>>>>>> <ic...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>> I attempted to build an RC, but failed repeatedly before realizing
>>>>>>>> it was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>>>>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>>>>>>> I'm about to wrap up the day's work.
>>>>>>>>
>>>>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya
>>>>>>>> <ic...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the
>>>>>>>>> release branch. It affects only the feature introduced in SOLR-8440. Please
>>>>>>>>> let me know if someone has any objections.
>>>>>>>>>
>>>>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let
>>>>>>>>> me know if there's something that someone is working on which needs to get
>>>>>>>>> in before that.
>>>>>>>>>
>>>>>>>>> Thanks and regards,
>>>>>>>>> Ishan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya
>>>>>>>>> <ic...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Sure Steve! Thanks!
>>>>>>>>>>
>>>>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Ishan,
>>>>>>>>>>>
>>>>>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>>>>>>> for 6.6?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Steve
>>>>>>>>>>> www.lucidworks.com
>>>>>>>>>>>
>>>>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi
>>>>>>>>>>> > <ji...@gmail.com> wrote:
>>>>>>>>>>> >
>>>>>>>>>>> > Ok thanks Ishan.
>>>>>>>>>>> >
>>>>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya"
>>>>>>>>>>> > <ic...@gmail.com> a écrit :
>>>>>>>>>>> > Sure, Jim. Please go ahead!
>>>>>>>>>>> >
>>>>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi
>>>>>>>>>>> > <ji...@gmail.com> wrote:
>>>>>>>>>>> > Hi,
>>>>>>>>>>> > Would be great to have
>>>>>>>>>>> > https://issues.apache.org/jira/browse/LUCENE-7824 included for 6.6. Can I
>>>>>>>>>>> > merge the fix this week end Ishan ?
>>>>>>>>>>> >
>>>>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya
>>>>>>>>>>> > <ic...@gmail.com>:
>>>>>>>>>>> > Done, Adrien. Thanks!
>>>>>>>>>>> >
>>>>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand
>>>>>>>>>>> > <jp...@gmail.com> wrote:
>>>>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>>>>>>> > well? I think it would help realize that the 6.6 branch has been cut when
>>>>>>>>>>> > looking at the CHANGES.txt file and not forget about backporting?
>>>>>>>>>>> >
>>>>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya
>>>>>>>>>>> > <ic...@gmail.com> a écrit :
>>>>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to
>>>>>>>>>>> > add bugfixes to the branch, if needed.
>>>>>>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>>>>>>> > there are any objections.
>>>>>>>>>>> >
>>>>>>>>>>> > Thanks,
>>>>>>>>>>> > Ishan
>>>>>>>>>>> >
>>>>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya
>>>>>>>>>>> > <ic...@gmail.com> wrote:
>>>>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>>>>>>> >
>>>>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty
>>>>>>>>>>> > <mg...@hotmail.com> wrote:
>>>>>>>>>>> > i was wondering if there was a specific test for
>>>>>>>>>>> > SpanPayloadCheckQuery method
>>>>>>>>>>> >
>>>>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>>>>>>> > SpanPayloadCheckQuery
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > I will submit JIRA with Patch
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>>>>>>> > sentence fragments (what we called phenomes) than current SEO
>>>>>>>>>>> > implementations
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > Can you suggest a book to read to better understand Lucenes
>>>>>>>>>>> > pattern dissection and match algorithms?
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > Many Thanks for helpful guidance
>>>>>>>>>>> > Martin
>>>>>>>>>>> > ______________________________________________
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>>>>>>> >
>>>>>>>>>>> > To: dev@lucene.apache.org
>>>>>>>>>>> > Subject: Re: Release 6.6
>>>>>>>>>>> >
>>>>>>>>>>> > Martin -
>>>>>>>>>>> >
>>>>>>>>>>> > I have to admit to still being unsure what the gist is here -
>>>>>>>>>>> > is there a bug?   Apologies for not catching what you’re saying/showing
>>>>>>>>>>> > here.  Again, as far as I can tell SpanPayloadCheckQuery is working as
>>>>>>>>>>> > expected now.
>>>>>>>>>>> >
>>>>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>>>>>>> > committed for 6.6.  If there is an issue to address with your work would you
>>>>>>>>>>> > please open a JIRA and include your patch there?
>>>>>>>>>>> >
>>>>>>>>>>> > Thanks,
>>>>>>>>>>> > Erik
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty
>>>>>>>>>>> >> <mg...@hotmail.com> wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Mornin' Erik
>>>>>>>>>>> >>
>>>>>>>>>>> >> there is a collectLeaf  override in
>>>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:
>>>>>>>>>>> >>
>>>>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>>>>>> >>     @Override
>>>>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int
>>>>>>>>>>> >> position, Term term) throws IOException {
>>>>>>>>>>> >>      ....
>>>>>>>>>>> >>      }
>>>>>>>>>>> >> }
>>>>>>>>>>> >>
>>>>>>>>>>> >> the modification in
>>>>>>>>>>> >> org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf
>>>>>>>>>>> >> for query
>>>>>>>>>>> >>
>>>>>>>>>>> >> //initialise term
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 231 before term1=new org.apache.lucene.index.Term('field','withPayload')");
>>>>>>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>>>>>>> >> org.apache.lucene.index.Term("field", "withPayload");
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 233 term1="+term1);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //assume position is 5
>>>>>>>>>>> >>     int position=5;
>>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>>> >> LINE 235 position="+position);
>>>>>>>>>>> >>
>>>>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>>> >> LINE 237 pay="+pay);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //build spanQuery with term parameter
>>>>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>>>>>>> >> SpanTermQuery(term1);
>>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>>> >> LINE 239 spanQuery1="+spanQuery1);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>>>>>>> >> payloadToMatch=new java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>>> >> LINE 241 payloadToMatch="+payloadToMatch);
>>>>>>>>>>> >>     payloadToMatch.add(pay);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //build SpanPayloadCheckQuery
>>>>>>>>>>> >> query=new
>>>>>>>>>>> >> org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>>>>>>> >>
>>>>>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 249 query="+query);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>>>>>>> >> directory with REAL test-data)
>>>>>>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>>>>>>> >> newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>>>>>>>>>> >>
>>>>>>>>>>> >> //build SegmentReader from Directory
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 251 ram="+ram);
>>>>>>>>>>> >> SegmentReader reader =
>>>>>>>>>>> >> getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 253 reader="+reader);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>>>>>>> >> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>>> >> LINE 255 sr="+sr);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //add term to SegmentReader postings
>>>>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>>>>>>>>>>> >> sr.postings(term1, PostingsEnum.PAYLOADS);
>>>>>>>>>>> >>
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 257 before
>>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>>>> >> postings="+postings);
>>>>>>>>>>> >>
>>>>>>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 258 before
>>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>>>> >> position="+position);
>>>>>>>>>>> >>
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >> 259 before
>>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>>>>>>> >>     try
>>>>>>>>>>> >>     { //public void
>>>>>>>>>>> >> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>>>>>> >> //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>>>>>>> >>
>>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>>>>> >> }
>>>>>>>>>>> >> catch(java.io.IOException ioe) {
>>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>>>>> >> IOException ="+ioe.getMessage()); }
>>>>>>>>>>> >>
>>>>>>>>>>> >> collectLeaf is the only method that compares
>>>>>>>>>>> >> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>>>>>> >> to determine "match"
>>>>>>>>>>> >>
>>>>>>>>>>> >> unless of course match between individual payload and
>>>>>>>>>>> >> payloadToMatch is tested elsewhere ?
>>>>>>>>>>> >>
>>>>>>>>>>> >> WDYT?
>>>>>>>>>>> >> Martin
>>>>>>>>>>> >> ______________________________________________
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>>>>>>> >> To: Lucene/Solr dev
>>>>>>>>>>> >> Subject: Re: Release 6.6
>>>>>>>>>>> >>
>>>>>>>>>>> >> Martin -
>>>>>>>>>>> >>
>>>>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out
>>>>>>>>>>> >> as it uses some logging and APIs that aren’t already in the project and
>>>>>>>>>>> >> classpath of these lucene tests within that queries module (within IntelliJ,
>>>>>>>>>>> >> mind you).
>>>>>>>>>>> >>
>>>>>>>>>>> >> I was able to resolve the misunderstanding (and
>>>>>>>>>>> >> .equals/.hashCode bugs) so everything is working as expected with
>>>>>>>>>>> >> SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or
>>>>>>>>>>> >> confirming that it is working properly at a lower level?
>>>>>>>>>>> >>
>>>>>>>>>>> >> Erik
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty
>>>>>>>>>>> >>> <mg...@hotmail.com> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view
>>>>>>>>>>> >>> it, click the link below.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> TestPayloadCheckQuery.java
>>>>>>>>>>> >>> attached
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>>>>>>> >>> modification properly addresses your situation
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Thanks!
>>>>>>>>>>> >>> Martin
>>>>>>>>>>> >>> ______________________________________________
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>>>>>>> >>> To: dev@lucene.apache.org
>>>>>>>>>>> >>> Subject: Re: Release 6.6
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Martin - there is a test class specifically for this query.
>>>>>>>>>>> >>> See the recent commits I've made to test it further fixing .equals/.hashCode
>>>>>>>>>>> >>> and rewrite.
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> Can you send your full test code?
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>    Erik
>>>>>>>>>>> >>>
>>>>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty
>>>>>>>>>>> >>> <mg...@hotmail.com> wrote:
>>>>>>>>>>> >>>
>>>>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to
>>>>>>>>>>> >>>> work I was about to reply just run that TestCase
>>>>>>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>>>>>>> >>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>>>>>>> >>>>   @org.junit.Test
>>>>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>>>>>>> >>>> construct query
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >>>> 257 before
>>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>>>> >>>> postings="+postings);
>>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >>>> 258 before
>>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>>>> >>>> position="+position);
>>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>>> >>>> 259 before
>>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>     try
>>>>>>>>>>> >>>>     { //test public void
>>>>>>>>>>> >>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>>>>>> >>>> //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>>>>> >>>> }
>>>>>>>>>>> >>>> catch(java.io.IOException ioe) {
>>>>>>>>>>> >>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>>>> >>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>>>>> >>>> IOException ="+ioe.getMessage()); }
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> unless of course anyone has a better idea to test
>>>>>>>>>>> >>>> collectLeaf ?
>>>>>>>>>>> >>>> Martin
>>>>>>>>>>> >>>> ______________________________________________
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>>>>>>> >>>> To: dev@lucene.apache.org
>>>>>>>>>>> >>>> Subject: Re: Release 6.6
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a
>>>>>>>>>>> >>>> good start (or will the 2.5 year old patch still apply and be acceptable
>>>>>>>>>>> >>>> as-is?)
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>> Erik
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood
>>>>>>>>>>> >>>>> <wu...@wunderwood.org> wrote:
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>> wunder
>>>>>>>>>>> >>>>> Walter Underwood
>>>>>>>>>>> >>>>> wunder@wunderwood.org
>>>>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya
>>>>>>>>>>> >>>>>> <ic...@gmail.com> wrote:
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Hi,
>>>>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6.
>>>>>>>>>>> >>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>>>>>>> >>>>>> before 7.0 release).
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>>>>>>> >>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>>>>>>> >>>>>> issues.
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> What do you think?
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>> Regards,
>>>>>>>>>>> >>>>>> Ishan
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>

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


Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Thanks for your help, Adrien!

On Wed, Jun 7, 2017 at 1:04 PM, Adrien Grand <jp...@gmail.com> wrote:

> Thank you Ishan for doing this release!
>
> Le mar. 6 juin 2017 à 01:16, Michael McCandless <lu...@mikemccandless.com>
> a écrit :
>
>> Thank you Ishan.
>>
>> I reviewed the Lucene release notes and it looks great!
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Mon, Jun 5, 2017 at 2:05 PM, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> Hi all,
>>> I've updated the release notes here:
>>> https://wiki.apache.org/lucene-java/ReleaseNote66
>>> https://wiki.apache.org/solr/ReleaseNote66
>>>
>>> Please review / feel free to edit.
>>> I have started the maven sync, so we have about 24 hours (for maven
>>> sync) until I update these to the website and announce the release.
>>> Thanks and regards,
>>> Ishan
>>>
>>> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com> wrote:
>>>
>>>> Sorry to hear that, make sure to take care of yourself first, the
>>>> release can wait! I just backported to branch_6_6.
>>>>
>>>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>
>>>>> Hi Adrien,
>>>>> Please proceed, by all means, to backport to release branch. I'm
>>>>> unwell today, and I haven't been able to start the RC cutting today;
>>>>> planning to do so after another 5-6 hours' rest.
>>>>> Thanks,
>>>>> Ishan
>>>>>
>>>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Ishan,
>>>>>>
>>>>>> I don't think it is worth restarting RC build in case you already
>>>>>> started, but in case you haven't started yet,
>>>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to
>>>>>> have in 6.6.
>>>>>>
>>>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>
>>>>>>> I attempted to build an RC, but failed repeatedly before realizing
>>>>>>> it was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>>>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>>>>>> I'm about to wrap up the day's work.
>>>>>>>
>>>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>
>>>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the
>>>>>>>> release branch. It affects only the feature introduced in SOLR-8440. Please
>>>>>>>> let me know if someone has any objections.
>>>>>>>>
>>>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let
>>>>>>>> me know if there's something that someone is working on which needs to get
>>>>>>>> in before that.
>>>>>>>>
>>>>>>>> Thanks and regards,
>>>>>>>> Ishan
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Sure Steve! Thanks!
>>>>>>>>>
>>>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Ishan,
>>>>>>>>>>
>>>>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>>>>>> for 6.6?
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Steve
>>>>>>>>>> www.lucidworks.com
>>>>>>>>>>
>>>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <
>>>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>>>> >
>>>>>>>>>> > Ok thanks Ishan.
>>>>>>>>>> >
>>>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>>>> > Sure, Jim. Please go ahead!
>>>>>>>>>> >
>>>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>>>> > Hi,
>>>>>>>>>> > Would be great to have https://issues.apache.org/
>>>>>>>>>> jira/browse/LUCENE-7824 included for 6.6. Can I merge the fix
>>>>>>>>>> this week end Ishan ?
>>>>>>>>>> >
>>>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>>>>>>>> ichattopadhyaya@gmail.com>:
>>>>>>>>>> > Done, Adrien. Thanks!
>>>>>>>>>> >
>>>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <
>>>>>>>>>> jpountz@gmail.com> wrote:
>>>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>>>>>> well? I think it would help realize that the 6.6 branch has been cut when
>>>>>>>>>> looking at the CHANGES.txt file and not forget about backporting?
>>>>>>>>>> >
>>>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to
>>>>>>>>>> add bugfixes to the branch, if needed.
>>>>>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>>>>>> there are any objections.
>>>>>>>>>> >
>>>>>>>>>> > Thanks,
>>>>>>>>>> > Ishan
>>>>>>>>>> >
>>>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>>>>>> >
>>>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <
>>>>>>>>>> mgainty@hotmail.com> wrote:
>>>>>>>>>> > i was wondering if there was a specific test for
>>>>>>>>>> SpanPayloadCheckQuery method
>>>>>>>>>> >
>>>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>>>>>> SpanPayloadCheckQuery
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > I will submit JIRA with Patch
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>>>>>> implementations
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > Can you suggest a book to read to better understand Lucenes
>>>>>>>>>> pattern dissection and match algorithms?
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > Many Thanks for helpful guidance
>>>>>>>>>> > Martin
>>>>>>>>>> > ______________________________________________
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>>>>>> >
>>>>>>>>>> > To: dev@lucene.apache.org
>>>>>>>>>> > Subject: Re: Release 6.6
>>>>>>>>>> >
>>>>>>>>>> > Martin -
>>>>>>>>>> >
>>>>>>>>>> > I have to admit to still being unsure what the gist is here -
>>>>>>>>>> is there a bug?   Apologies for not catching what you’re saying/showing
>>>>>>>>>> here.  Again, as far as I can tell SpanPayloadCheckQuery is working as
>>>>>>>>>> expected now.
>>>>>>>>>> >
>>>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>>>>>> committed for 6.6.  If there is an issue to address with your work would
>>>>>>>>>> you please open a JIRA and include your patch there?
>>>>>>>>>> >
>>>>>>>>>> > Thanks,
>>>>>>>>>> > Erik
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <
>>>>>>>>>> mgainty@hotmail.com> wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> Mornin' Erik
>>>>>>>>>> >>
>>>>>>>>>> >> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans
>>>>>>>>>> ..but its never called:
>>>>>>>>>> >>
>>>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>>>>> >>     @Override
>>>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int
>>>>>>>>>> position, Term term) throws IOException {
>>>>>>>>>> >>      ....
>>>>>>>>>> >>      }
>>>>>>>>>> >> }
>>>>>>>>>> >>
>>>>>>>>>> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>>>>>>>>>> tests collectLeaf for query
>>>>>>>>>> >>
>>>>>>>>>> >> //initialise term
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 231 before term1=new org.apache.lucene.index.Term('
>>>>>>>>>> field','withPayload')");
>>>>>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>>>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 233 term1="+term1);
>>>>>>>>>> >>
>>>>>>>>>> >> //assume position is 5
>>>>>>>>>> >>     int position=5;
>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>> LINE 235 position="+position);
>>>>>>>>>> >>
>>>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>> LINE 237 pay="+pay);
>>>>>>>>>> >>
>>>>>>>>>> >> //build spanQuery with term parameter
>>>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>>>>>> SpanTermQuery(term1);
>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>> LINE 239 spanQuery1="+spanQuery1);
>>>>>>>>>> >>
>>>>>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>>>>>> payloadToMatch=new java.util.ArrayList<org.
>>>>>>>>>> apache.lucene.util.BytesRef>();
>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>> LINE 241 payloadToMatch="+payloadToMatch);
>>>>>>>>>> >>     payloadToMatch.add(pay);
>>>>>>>>>> >>
>>>>>>>>>> >> //build SpanPayloadCheckQuery
>>>>>>>>>> >> query=new org.apache.lucene.queries.payloads.
>>>>>>>>>> SpanPayloadCheckQuery(
>>>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)
>>>>>>>>>> payloadToMatch);
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 249 query="+query);
>>>>>>>>>> >>
>>>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>>>>>> directory with REAL test-data)
>>>>>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>>>>>> newDirectory(com.carrotsearch.randomizedtesting.
>>>>>>>>>> RandomizedContext.current().getRandom());
>>>>>>>>>> >>
>>>>>>>>>> >> //build SegmentReader from Directory
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 251 ram="+ram);
>>>>>>>>>> >> SegmentReader reader = getOnlySegmentReader(org.
>>>>>>>>>> apache.lucene.index.DirectoryReader.open(ram));
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 253 reader="+reader);
>>>>>>>>>> >>
>>>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>>>> LINE 255 sr="+sr);
>>>>>>>>>> >>
>>>>>>>>>> >> //add term to SegmentReader postings
>>>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>>>>>>>>>> sr.postings(term1, PostingsEnum.PAYLOADS);
>>>>>>>>>> >>
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 257 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> where postings="+postings);
>>>>>>>>>> >>
>>>>>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 258 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> where position="+position);
>>>>>>>>>> >>
>>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 259 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> where term1="+term1);
>>>>>>>>>> >>     try
>>>>>>>>>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>>>>> postings, int position,       //org.apache.lucene.index.Term
>>>>>>>>>> term) throws java.io.IOException {
>>>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>>>>>>>> lucene.index.Term)term1);
>>>>>>>>>> >> }
>>>>>>>>>> >> catch(java.io.IOException ioe) { log.debug("
>>>>>>>>>> TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>>>>>>> >>
>>>>>>>>>> >> collectLeaf is the only method that compares
>>>>>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>>>>> >> to determine "match"
>>>>>>>>>> >>
>>>>>>>>>> >> unless of course match between individual payload and
>>>>>>>>>> payloadToMatch is tested elsewhere ?
>>>>>>>>>> >>
>>>>>>>>>> >> WDYT?
>>>>>>>>>> >> Martin
>>>>>>>>>> >> ______________________________________________
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>>>>>> >> To: Lucene/Solr dev
>>>>>>>>>> >> Subject: Re: Release 6.6
>>>>>>>>>> >>
>>>>>>>>>> >> Martin -
>>>>>>>>>> >>
>>>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out
>>>>>>>>>> as it uses some logging and APIs that aren’t already in the project and
>>>>>>>>>> classpath of these lucene tests within that queries module (within
>>>>>>>>>> IntelliJ, mind you).
>>>>>>>>>> >>
>>>>>>>>>> >> I was able to resolve the misunderstanding (and
>>>>>>>>>> .equals/.hashCode bugs) so everything is working as expected with
>>>>>>>>>> SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or
>>>>>>>>>> confirming that it is working properly at a lower level?
>>>>>>>>>> >>
>>>>>>>>>> >> Erik
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <
>>>>>>>>>> mgainty@hotmail.com> wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view
>>>>>>>>>> it, click the link below.
>>>>>>>>>> >>>
>>>>>>>>>> >>> TestPayloadCheckQuery.java
>>>>>>>>>> >>> attached
>>>>>>>>>> >>>
>>>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>>>>>> >>>
>>>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>>>>>> modification properly addresses your situation
>>>>>>>>>> >>>
>>>>>>>>>> >>> Thanks!
>>>>>>>>>> >>> Martin
>>>>>>>>>> >>> ______________________________________________
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>>
>>>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>>>>>> >>> To: dev@lucene.apache.org
>>>>>>>>>> >>> Subject: Re: Release 6.6
>>>>>>>>>> >>>
>>>>>>>>>> >>> Martin - there is a test class specifically for this query.
>>>>>>>>>>  See the recent commits I've made to test it further fixing
>>>>>>>>>> .equals/.hashCode and rewrite.
>>>>>>>>>> >>>
>>>>>>>>>> >>> Can you send your full test code?
>>>>>>>>>> >>>
>>>>>>>>>> >>>    Erik
>>>>>>>>>> >>>
>>>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> >>>
>>>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to
>>>>>>>>>> work I was about to reply just run that TestCase
>>>>>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>>>>>> >>>>   @org.junit.Test
>>>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>>>>>> construct query
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 257 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> where postings="+postings);
>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 258 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> where position="+position);
>>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>>> 259 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> where term1="+term1);
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>     try
>>>>>>>>>> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>>>>> postings, int position,              //org.apache.lucene.index.Term term)
>>>>>>>>>> throws java.io.IOException {
>>>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>>>>>>>> lucene.index.Term)term1);
>>>>>>>>>> >>>> }
>>>>>>>>>> >>>> catch(java.io.IOException ioe) { log.error("
>>>>>>>>>> TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> unless of course anyone has a better idea to test
>>>>>>>>>> collectLeaf ?
>>>>>>>>>> >>>> Martin
>>>>>>>>>> >>>> ______________________________________________
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>>>>>> >>>> To: dev@lucene.apache.org
>>>>>>>>>> >>>> Subject: Re: Release 6.6
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a
>>>>>>>>>> good start (or will the 2.5 year old patch still apply and be acceptable
>>>>>>>>>> as-is?)
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Erik
>>>>>>>>>> >>>>
>>>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>>>>>>>> wunder@wunderwood.org> wrote:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> wunder
>>>>>>>>>> >>>>> Walter Underwood
>>>>>>>>>> >>>>> wunder@wunderwood.org
>>>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> Hi,
>>>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6.
>>>>>>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>>>>>> before 7.0 release).
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>>>>>> issues.
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> What do you think?
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>> Regards,
>>>>>>>>>> >>>>>> Ishan
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>> ---------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>

Re: Release 6.6

Posted by Adrien Grand <jp...@gmail.com>.
Thank you Ishan for doing this release!

Le mar. 6 juin 2017 à 01:16, Michael McCandless <lu...@mikemccandless.com>
a écrit :

> Thank you Ishan.
>
> I reviewed the Lucene release notes and it looks great!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Mon, Jun 5, 2017 at 2:05 PM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> Hi all,
>> I've updated the release notes here:
>> https://wiki.apache.org/lucene-java/ReleaseNote66
>> https://wiki.apache.org/solr/ReleaseNote66
>>
>> Please review / feel free to edit.
>> I have started the maven sync, so we have about 24 hours (for maven sync)
>> until I update these to the website and announce the release.
>> Thanks and regards,
>> Ishan
>>
>> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com> wrote:
>>
>>> Sorry to hear that, make sure to take care of yourself first, the
>>> release can wait! I just backported to branch_6_6.
>>>
>>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> a écrit :
>>>
>>>> Hi Adrien,
>>>> Please proceed, by all means, to backport to release branch. I'm unwell
>>>> today, and I haven't been able to start the RC cutting today; planning to
>>>> do so after another 5-6 hours' rest.
>>>> Thanks,
>>>> Ishan
>>>>
>>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Ishan,
>>>>>
>>>>> I don't think it is worth restarting RC build in case you already
>>>>> started, but in case you haven't started yet,
>>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to
>>>>> have in 6.6.
>>>>>
>>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>
>>>>>> I attempted to build an RC, but failed repeatedly before realizing it
>>>>>> was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>>>>> I'm about to wrap up the day's work.
>>>>>>
>>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>
>>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>>>>>>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>>>>>>> know if someone has any objections.
>>>>>>>
>>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let
>>>>>>> me know if there's something that someone is working on which needs to get
>>>>>>> in before that.
>>>>>>>
>>>>>>> Thanks and regards,
>>>>>>> Ishan
>>>>>>>
>>>>>>>
>>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>
>>>>>>>> Sure Steve! Thanks!
>>>>>>>>
>>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ishan,
>>>>>>>>>
>>>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>>>>> for 6.6?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Steve
>>>>>>>>> www.lucidworks.com
>>>>>>>>>
>>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <
>>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>>> >
>>>>>>>>> > Ok thanks Ishan.
>>>>>>>>> >
>>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>>> > Sure, Jim. Please go ahead!
>>>>>>>>> >
>>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>>> > Hi,
>>>>>>>>> > Would be great to have
>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE-7824 included for
>>>>>>>>> 6.6. Can I merge the fix this week end Ishan ?
>>>>>>>>> >
>>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>>>>>>> ichattopadhyaya@gmail.com>:
>>>>>>>>> > Done, Adrien. Thanks!
>>>>>>>>> >
>>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>>>>> well? I think it would help realize that the 6.6 branch has been cut when
>>>>>>>>> looking at the CHANGES.txt file and not forget about backporting?
>>>>>>>>> >
>>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to
>>>>>>>>> add bugfixes to the branch, if needed.
>>>>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>>>>> there are any objections.
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > Ishan
>>>>>>>>> >
>>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>>>>> >
>>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <
>>>>>>>>> mgainty@hotmail.com> wrote:
>>>>>>>>> > i was wondering if there was a specific test for
>>>>>>>>> SpanPayloadCheckQuery method
>>>>>>>>> >
>>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>>>>> SpanPayloadCheckQuery
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > I will submit JIRA with Patch
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>>>>> implementations
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Can you suggest a book to read to better understand Lucenes
>>>>>>>>> pattern dissection and match algorithms?
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Many Thanks for helpful guidance
>>>>>>>>> > Martin
>>>>>>>>> > ______________________________________________
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>>>>> >
>>>>>>>>> > To: dev@lucene.apache.org
>>>>>>>>> > Subject: Re: Release 6.6
>>>>>>>>> >
>>>>>>>>> > Martin -
>>>>>>>>> >
>>>>>>>>> > I have to admit to still being unsure what the gist is here - is
>>>>>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>>>>> now.
>>>>>>>>> >
>>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>>>>> committed for 6.6.  If there is an issue to address with your work would
>>>>>>>>> you please open a JIRA and include your patch there?
>>>>>>>>> >
>>>>>>>>> > Thanks,
>>>>>>>>> > Erik
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >> Mornin' Erik
>>>>>>>>> >>
>>>>>>>>> >> there is a collectLeaf  override in
>>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:
>>>>>>>>> >>
>>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>>>> >>     @Override
>>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int
>>>>>>>>> position, Term term) throws IOException {
>>>>>>>>> >>      ....
>>>>>>>>> >>      }
>>>>>>>>> >> }
>>>>>>>>> >>
>>>>>>>>> >> the modification in
>>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf
>>>>>>>>> for query
>>>>>>>>> >>
>>>>>>>>> >> //initialise term
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>>>>> before term1=new org.apache.lucene.index.Term('field','withPayload')");
>>>>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>>>>> term1="+term1);
>>>>>>>>> >>
>>>>>>>>> >> //assume position is 5
>>>>>>>>> >>     int position=5;
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 235 position="+position);
>>>>>>>>> >>
>>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 237 pay="+pay);
>>>>>>>>> >>
>>>>>>>>> >> //build spanQuery with term parameter
>>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>>>>> SpanTermQuery(term1);
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 239 spanQuery1="+spanQuery1);
>>>>>>>>> >>
>>>>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>>>>> payloadToMatch=new java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 241 payloadToMatch="+payloadToMatch);
>>>>>>>>> >>     payloadToMatch.add(pay);
>>>>>>>>> >>
>>>>>>>>> >> //build SpanPayloadCheckQuery
>>>>>>>>> >> query=new
>>>>>>>>> org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>>>>> >>
>>>>>>>>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>>>>> query="+query);
>>>>>>>>> >>
>>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>>>>> directory with REAL test-data)
>>>>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>>>>>>>> >>
>>>>>>>>> >> //build SegmentReader from Directory
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>>>>> ram="+ram);
>>>>>>>>> >> SegmentReader reader =
>>>>>>>>> getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>>>>> reader="+reader);
>>>>>>>>> >>
>>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 255 sr="+sr);
>>>>>>>>> >>
>>>>>>>>> >> //add term to SegmentReader postings
>>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>>>>>>>>> sr.postings(term1, PostingsEnum.PAYLOADS);
>>>>>>>>> >>
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>>>>> before
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> postings="+postings);
>>>>>>>>> >>
>>>>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>>>>> before
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> position="+position);
>>>>>>>>> >>
>>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>>>>> before
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>>>>> >>     try
>>>>>>>>> >>     { //public void
>>>>>>>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>>>>    //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>>>>> >>
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>>> >> }
>>>>>>>>> >> catch(java.io.IOException ioe) {
>>>>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>>>> >>
>>>>>>>>> >> collectLeaf is the only method that compares
>>>>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>>>> >> to determine "match"
>>>>>>>>> >>
>>>>>>>>> >> unless of course match between individual payload and
>>>>>>>>> payloadToMatch is tested elsewhere ?
>>>>>>>>> >>
>>>>>>>>> >> WDYT?
>>>>>>>>> >> Martin
>>>>>>>>> >> ______________________________________________
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>>>>> >> To: Lucene/Solr dev
>>>>>>>>> >> Subject: Re: Release 6.6
>>>>>>>>> >>
>>>>>>>>> >> Martin -
>>>>>>>>> >>
>>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out
>>>>>>>>> as it uses some logging and APIs that aren’t already in the project and
>>>>>>>>> classpath of these lucene tests within that queries module (within
>>>>>>>>> IntelliJ, mind you).
>>>>>>>>> >>
>>>>>>>>> >> I was able to resolve the misunderstanding (and
>>>>>>>>> .equals/.hashCode bugs) so everything is working as expected with
>>>>>>>>> SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or
>>>>>>>>> confirming that it is working properly at a lower level?
>>>>>>>>> >>
>>>>>>>>> >> Erik
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <
>>>>>>>>> mgainty@hotmail.com> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>>>>>>> click the link below.
>>>>>>>>> >>>
>>>>>>>>> >>> TestPayloadCheckQuery.java
>>>>>>>>> >>> attached
>>>>>>>>> >>>
>>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>>>>> >>>
>>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>>>>> modification properly addresses your situation
>>>>>>>>> >>>
>>>>>>>>> >>> Thanks!
>>>>>>>>> >>> Martin
>>>>>>>>> >>> ______________________________________________
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>>>>> >>> To: dev@lucene.apache.org
>>>>>>>>> >>> Subject: Re: Release 6.6
>>>>>>>>> >>>
>>>>>>>>> >>> Martin - there is a test class specifically for this query.
>>>>>>>>>  See the recent commits I've made to test it further fixing
>>>>>>>>> .equals/.hashCode and rewrite.
>>>>>>>>> >>>
>>>>>>>>> >>> Can you send your full test code?
>>>>>>>>> >>>
>>>>>>>>> >>>    Erik
>>>>>>>>> >>>
>>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to
>>>>>>>>> work I was about to reply just run that TestCase
>>>>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>>>>> >>>>
>>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>>>>> >>>>   @org.junit.Test
>>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>>>> >>>>
>>>>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>>>>> construct query
>>>>>>>>> >>>>
>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 257 before
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> postings="+postings);
>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 258 before
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>>> position="+position);
>>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>>> 259 before
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>>>>> >>>>
>>>>>>>>> >>>>     try
>>>>>>>>> >>>>     { //test public void
>>>>>>>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>>>>           //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>>>>> >>>>
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>>> >>>> }
>>>>>>>>> >>>> catch(java.io.IOException ioe) {
>>>>>>>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>>>> >>>>
>>>>>>>>> >>>> unless of course anyone has a better idea to test collectLeaf
>>>>>>>>> ?
>>>>>>>>> >>>> Martin
>>>>>>>>> >>>> ______________________________________________
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>>>>> >>>> To: dev@lucene.apache.org
>>>>>>>>> >>>> Subject: Re: Release 6.6
>>>>>>>>> >>>>
>>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a
>>>>>>>>> good start (or will the 2.5 year old patch still apply and be acceptable
>>>>>>>>> as-is?)
>>>>>>>>> >>>>
>>>>>>>>> >>>> Erik
>>>>>>>>> >>>>
>>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>>>>>>> wunder@wunderwood.org> wrote:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> wunder
>>>>>>>>> >>>>> Walter Underwood
>>>>>>>>> >>>>> wunder@wunderwood.org
>>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Hi,
>>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6.
>>>>>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>>>>> before 7.0 release).
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>>>>> issues.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> What do you think?
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Regards,
>>>>>>>>> >>>>>> Ishan
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

Re: Release 6.6

Posted by Michael McCandless <lu...@mikemccandless.com>.
Thank you Ishan.

I reviewed the Lucene release notes and it looks great!

Mike McCandless

http://blog.mikemccandless.com

On Mon, Jun 5, 2017 at 2:05 PM, Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> Hi all,
> I've updated the release notes here:
> https://wiki.apache.org/lucene-java/ReleaseNote66
> https://wiki.apache.org/solr/ReleaseNote66
>
> Please review / feel free to edit.
> I have started the maven sync, so we have about 24 hours (for maven sync)
> until I update these to the website and announce the release.
> Thanks and regards,
> Ishan
>
> On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com> wrote:
>
>> Sorry to hear that, make sure to take care of yourself first, the release
>> can wait! I just backported to branch_6_6.
>>
>> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> a écrit :
>>
>>> Hi Adrien,
>>> Please proceed, by all means, to backport to release branch. I'm unwell
>>> today, and I haven't been able to start the RC cutting today; planning to
>>> do so after another 5-6 hours' rest.
>>> Thanks,
>>> Ishan
>>>
>>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com>
>>> wrote:
>>>
>>>> Hi Ishan,
>>>>
>>>> I don't think it is worth restarting RC build in case you already
>>>> started, but in case you haven't started yet,
>>>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to
>>>> have in 6.6.
>>>>
>>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>
>>>>> I attempted to build an RC, but failed repeatedly before realizing it
>>>>> was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>>>> I'm about to wrap up the day's work.
>>>>>
>>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>
>>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>>>>>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>>>>>> know if someone has any objections.
>>>>>>
>>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let
>>>>>> me know if there's something that someone is working on which needs to get
>>>>>> in before that.
>>>>>>
>>>>>> Thanks and regards,
>>>>>> Ishan
>>>>>>
>>>>>>
>>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>
>>>>>>> Sure Steve! Thanks!
>>>>>>>
>>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ishan,
>>>>>>>>
>>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>>>> for 6.6?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Steve
>>>>>>>> www.lucidworks.com
>>>>>>>>
>>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <
>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>> >
>>>>>>>> > Ok thanks Ishan.
>>>>>>>> >
>>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>> > Sure, Jim. Please go ahead!
>>>>>>>> >
>>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>>> > Hi,
>>>>>>>> > Would be great to have https://issues.apache.org/jira
>>>>>>>> /browse/LUCENE-7824 included for 6.6. Can I merge the fix this
>>>>>>>> week end Ishan ?
>>>>>>>> >
>>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com>:
>>>>>>>> > Done, Adrien. Thanks!
>>>>>>>> >
>>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>>>> well? I think it would help realize that the 6.6 branch has been cut when
>>>>>>>> looking at the CHANGES.txt file and not forget about backporting?
>>>>>>>> >
>>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to
>>>>>>>> add bugfixes to the branch, if needed.
>>>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>>>> there are any objections.
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > Ishan
>>>>>>>> >
>>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>>>> >
>>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <
>>>>>>>> mgainty@hotmail.com> wrote:
>>>>>>>> > i was wondering if there was a specific test for
>>>>>>>> SpanPayloadCheckQuery method
>>>>>>>> >
>>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>>>> SpanPayloadCheckQuery
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > I will submit JIRA with Patch
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>>>> implementations
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Can you suggest a book to read to better understand Lucenes
>>>>>>>> pattern dissection and match algorithms?
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Many Thanks for helpful guidance
>>>>>>>> > Martin
>>>>>>>> > ______________________________________________
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>>>> >
>>>>>>>> > To: dev@lucene.apache.org
>>>>>>>> > Subject: Re: Release 6.6
>>>>>>>> >
>>>>>>>> > Martin -
>>>>>>>> >
>>>>>>>> > I have to admit to still being unsure what the gist is here - is
>>>>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>>>> now.
>>>>>>>> >
>>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>>>> committed for 6.6.  If there is an issue to address with your work would
>>>>>>>> you please open a JIRA and include your patch there?
>>>>>>>> >
>>>>>>>> > Thanks,
>>>>>>>> > Erik
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> Mornin' Erik
>>>>>>>> >>
>>>>>>>> >> there is a collectLeaf  override in
>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its
>>>>>>>> never called:
>>>>>>>> >>
>>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>>> >>     @Override
>>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int position,
>>>>>>>> Term term) throws IOException {
>>>>>>>> >>      ....
>>>>>>>> >>      }
>>>>>>>> >> }
>>>>>>>> >>
>>>>>>>> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>>>>>>>> tests collectLeaf for query
>>>>>>>> >>
>>>>>>>> >> //initialise term
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>>>> before term1=new org.apache.lucene.index.Term('
>>>>>>>> field','withPayload')");
>>>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>>>> term1="+term1);
>>>>>>>> >>
>>>>>>>> >> //assume position is 5
>>>>>>>> >>     int position=5;
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 235 position="+position);
>>>>>>>> >>
>>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 237 pay="+pay);
>>>>>>>> >>
>>>>>>>> >> //build spanQuery with term parameter
>>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>>>> SpanTermQuery(term1);
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 239 spanQuery1="+spanQuery1);
>>>>>>>> >>
>>>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>>>> payloadToMatch=new java.util.ArrayList<org.apache
>>>>>>>> .lucene.util.BytesRef>();
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 241 payloadToMatch="+payloadToMatch);
>>>>>>>> >>     payloadToMatch.add(pay);
>>>>>>>> >>
>>>>>>>> >> //build SpanPayloadCheckQuery
>>>>>>>> >> query=new org.apache.lucene.queries.payl
>>>>>>>> oads.SpanPayloadCheckQuery(
>>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMa
>>>>>>>> tch);
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>>>> query="+query);
>>>>>>>> >>
>>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>>>> directory with REAL test-data)
>>>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedCo
>>>>>>>> ntext.current().getRandom());
>>>>>>>> >>
>>>>>>>> >> //build SegmentReader from Directory
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>>>> ram="+ram);
>>>>>>>> >> SegmentReader reader = getOnlySegmentReader(org.apach
>>>>>>>> e.lucene.index.DirectoryReader.open(ram));
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>>>> reader="+reader);
>>>>>>>> >>
>>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 255 sr="+sr);
>>>>>>>> >>
>>>>>>>> >> //add term to SegmentReader postings
>>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>>>>>>>> sr.postings(term1, PostingsEnum.PAYLOADS);
>>>>>>>> >>
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> postings="+postings);
>>>>>>>> >>
>>>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> position="+position);
>>>>>>>> >>
>>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> term1="+term1);
>>>>>>>> >>     try
>>>>>>>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>>> postings, int position,       //org.apache.lucene.index.Term term)
>>>>>>>> throws java.io.IOException {
>>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>> >> }
>>>>>>>> >> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>>> >>
>>>>>>>> >> collectLeaf is the only method that compares
>>>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>>> >> to determine "match"
>>>>>>>> >>
>>>>>>>> >> unless of course match between individual payload and
>>>>>>>> payloadToMatch is tested elsewhere ?
>>>>>>>> >>
>>>>>>>> >> WDYT?
>>>>>>>> >> Martin
>>>>>>>> >> ______________________________________________
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>>>> >> To: Lucene/Solr dev
>>>>>>>> >> Subject: Re: Release 6.6
>>>>>>>> >>
>>>>>>>> >> Martin -
>>>>>>>> >>
>>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out
>>>>>>>> as it uses some logging and APIs that aren’t already in the project and
>>>>>>>> classpath of these lucene tests within that queries module (within
>>>>>>>> IntelliJ, mind you).
>>>>>>>> >>
>>>>>>>> >> I was able to resolve the misunderstanding (and
>>>>>>>> .equals/.hashCode bugs) so everything is working as expected with
>>>>>>>> SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or
>>>>>>>> confirming that it is working properly at a lower level?
>>>>>>>> >>
>>>>>>>> >> Erik
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>>> wrote:
>>>>>>>> >>>
>>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>>>>>> click the link below.
>>>>>>>> >>>
>>>>>>>> >>> TestPayloadCheckQuery.java
>>>>>>>> >>> attached
>>>>>>>> >>>
>>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>>>> >>>
>>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>>>> modification properly addresses your situation
>>>>>>>> >>>
>>>>>>>> >>> Thanks!
>>>>>>>> >>> Martin
>>>>>>>> >>> ______________________________________________
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>>>> >>> To: dev@lucene.apache.org
>>>>>>>> >>> Subject: Re: Release 6.6
>>>>>>>> >>>
>>>>>>>> >>> Martin - there is a test class specifically for this query.
>>>>>>>>  See the recent commits I've made to test it further fixing
>>>>>>>> .equals/.hashCode and rewrite.
>>>>>>>> >>>
>>>>>>>> >>> Can you send your full test code?
>>>>>>>> >>>
>>>>>>>> >>>    Erik
>>>>>>>> >>>
>>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>>>>> wrote:
>>>>>>>> >>>
>>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to
>>>>>>>> work I was about to reply just run that TestCase
>>>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>>>> >>>>
>>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>>>> >>>>   @org.junit.Test
>>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>>> >>>>
>>>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>>>> construct query
>>>>>>>> >>>>
>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 257 before query.getPayloadChecker().coll
>>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> postings="+postings);
>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 258 before query.getPayloadChecker().coll
>>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> position="+position);
>>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>>> 259 before query.getPayloadChecker().coll
>>>>>>>> ectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>>>> term1="+term1);
>>>>>>>> >>>>
>>>>>>>> >>>>     try
>>>>>>>> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>>> postings, int position,              //org.apache.lucene.index.Term term)
>>>>>>>> throws java.io.IOException {
>>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>>>> >>>> }
>>>>>>>> >>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>>> >>>>
>>>>>>>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>>>>> >>>> Martin
>>>>>>>> >>>> ______________________________________________
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>>>> >>>> To: dev@lucene.apache.org
>>>>>>>> >>>> Subject: Re: Release 6.6
>>>>>>>> >>>>
>>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>>>>>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>>>> >>>>
>>>>>>>> >>>> Erik
>>>>>>>> >>>>
>>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>>>>>> wunder@wunderwood.org> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>>> >>>>>
>>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>>> >>>>>
>>>>>>>> >>>>> wunder
>>>>>>>> >>>>> Walter Underwood
>>>>>>>> >>>>> wunder@wunderwood.org
>>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> Hi,
>>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6.
>>>>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>>>> before 7.0 release).
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>>>> issues.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> What do you think?
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> Regards,
>>>>>>>> >>>>>> Ishan
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Hi all,
I've updated the release notes here:
https://wiki.apache.org/lucene-java/ReleaseNote66
https://wiki.apache.org/solr/ReleaseNote66

Please review / feel free to edit.
I have started the maven sync, so we have about 24 hours (for maven sync)
until I update these to the website and announce the release.
Thanks and regards,
Ishan

On Wed, May 17, 2017 at 2:43 AM, Adrien Grand <jp...@gmail.com> wrote:

> Sorry to hear that, make sure to take care of yourself first, the release
> can wait! I just backported to branch_6_6.
>
> Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> a écrit :
>
>> Hi Adrien,
>> Please proceed, by all means, to backport to release branch. I'm unwell
>> today, and I haven't been able to start the RC cutting today; planning to
>> do so after another 5-6 hours' rest.
>> Thanks,
>> Ishan
>>
>> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com> wrote:
>>
>>> Hi Ishan,
>>>
>>> I don't think it is worth restarting RC build in case you already
>>> started, but in case you haven't started yet, https://issues.apache.org/
>>> jira/browse/LUCENE-7831 could be nice to have in 6.6.
>>>
>>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> a écrit :
>>>
>>>> I attempted to build an RC, but failed repeatedly before realizing it
>>>> was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>>> I'm about to wrap up the day's work.
>>>>
>>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>>
>>>>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>>>>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>>>>> know if someone has any objections.
>>>>>
>>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let me
>>>>> know if there's something that someone is working on which needs to get in
>>>>> before that.
>>>>>
>>>>> Thanks and regards,
>>>>> Ishan
>>>>>
>>>>>
>>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>
>>>>>> Sure Steve! Thanks!
>>>>>>
>>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com> wrote:
>>>>>>
>>>>>>> Ishan,
>>>>>>>
>>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>>> for 6.6?
>>>>>>>
>>>>>>> --
>>>>>>> Steve
>>>>>>> www.lucidworks.com
>>>>>>>
>>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Ok thanks Ishan.
>>>>>>> >
>>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>> > Sure, Jim. Please go ahead!
>>>>>>> >
>>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>> > Hi,
>>>>>>> > Would be great to have https://issues.apache.org/
>>>>>>> jira/browse/LUCENE-7824 included for 6.6. Can I merge the fix this
>>>>>>> week end Ishan ?
>>>>>>> >
>>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>>>>> ichattopadhyaya@gmail.com>:
>>>>>>> > Done, Adrien. Thanks!
>>>>>>> >
>>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>>>>> wrote:
>>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>>> well? I think it would help realize that the 6.6 branch has been cut when
>>>>>>> looking at the CHANGES.txt file and not forget about backporting?
>>>>>>> >
>>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>>>>>> bugfixes to the branch, if needed.
>>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>>> there are any objections.
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Ishan
>>>>>>> >
>>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>>> >
>>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>>>>>> wrote:
>>>>>>> > i was wondering if there was a specific test for
>>>>>>> SpanPayloadCheckQuery method
>>>>>>> >
>>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>>> SpanPayloadCheckQuery
>>>>>>> >
>>>>>>> >
>>>>>>> > I will submit JIRA with Patch
>>>>>>> >
>>>>>>> >
>>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>>> implementations
>>>>>>> >
>>>>>>> >
>>>>>>> > Can you suggest a book to read to better understand Lucenes
>>>>>>> pattern dissection and match algorithms?
>>>>>>> >
>>>>>>> >
>>>>>>> > Many Thanks for helpful guidance
>>>>>>> > Martin
>>>>>>> > ______________________________________________
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>>> >
>>>>>>> > To: dev@lucene.apache.org
>>>>>>> > Subject: Re: Release 6.6
>>>>>>> >
>>>>>>> > Martin -
>>>>>>> >
>>>>>>> > I have to admit to still being unsure what the gist is here - is
>>>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>>> now.
>>>>>>> >
>>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>>> committed for 6.6.  If there is an issue to address with your work would
>>>>>>> you please open a JIRA and include your patch there?
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > Erik
>>>>>>> >
>>>>>>> >
>>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>> wrote:
>>>>>>> >>
>>>>>>> >> Mornin' Erik
>>>>>>> >>
>>>>>>> >> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans
>>>>>>> ..but its never called:
>>>>>>> >>
>>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>> >>     @Override
>>>>>>> >>     public void collectLeaf(PostingsEnum postings, int position,
>>>>>>> Term term) throws IOException {
>>>>>>> >>      ....
>>>>>>> >>      }
>>>>>>> >> }
>>>>>>> >>
>>>>>>> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>>>>>>> tests collectLeaf for query
>>>>>>> >>
>>>>>>> >> //initialise term
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>>> before term1=new org.apache.lucene.index.Term('
>>>>>>> field','withPayload')");
>>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>>> term1="+term1);
>>>>>>> >>
>>>>>>> >> //assume position is 5
>>>>>>> >>     int position=5;
>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 235 position="+position);
>>>>>>> >>
>>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 237 pay="+pay);
>>>>>>> >>
>>>>>>> >> //build spanQuery with term parameter
>>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>>> SpanTermQuery(term1);
>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 239 spanQuery1="+spanQuery1);
>>>>>>> >>
>>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>>> payloadToMatch=new java.util.ArrayList<org.
>>>>>>> apache.lucene.util.BytesRef>();
>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 241 payloadToMatch="+payloadToMatch);
>>>>>>> >>     payloadToMatch.add(pay);
>>>>>>> >>
>>>>>>> >> //build SpanPayloadCheckQuery
>>>>>>> >> query=new org.apache.lucene.queries.payloads.
>>>>>>> SpanPayloadCheckQuery(
>>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>>> query="+query);
>>>>>>> >>
>>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>>> directory with REAL test-data)
>>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>>> newDirectory(com.carrotsearch.randomizedtesting.
>>>>>>> RandomizedContext.current().getRandom());
>>>>>>> >>
>>>>>>> >> //build SegmentReader from Directory
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>>> ram="+ram);
>>>>>>> >> SegmentReader reader = getOnlySegmentReader(org.
>>>>>>> apache.lucene.index.DirectoryReader.open(ram));
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>>> reader="+reader);
>>>>>>> >>
>>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 255 sr="+sr);
>>>>>>> >>
>>>>>>> >> //add term to SegmentReader postings
>>>>>>> >> org.apache.lucene.index.PostingsEnum postings =
>>>>>>> sr.postings(term1, PostingsEnum.PAYLOADS);
>>>>>>> >>
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> where postings="+postings);
>>>>>>> >>
>>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> where position="+position);
>>>>>>> >>
>>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> where term1="+term1);
>>>>>>> >>     try
>>>>>>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>> postings, int position,       //org.apache.lucene.index.Term term)
>>>>>>> throws java.io.IOException {
>>>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>>>>> lucene.index.Term)term1);
>>>>>>> >> }
>>>>>>> >> catch(java.io.IOException ioe) { log.debug("
>>>>>>> TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>>>> >>
>>>>>>> >> collectLeaf is the only method that compares
>>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>> >> to determine "match"
>>>>>>> >>
>>>>>>> >> unless of course match between individual payload and
>>>>>>> payloadToMatch is tested elsewhere ?
>>>>>>> >>
>>>>>>> >> WDYT?
>>>>>>> >> Martin
>>>>>>> >> ______________________________________________
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>>> >> To: Lucene/Solr dev
>>>>>>> >> Subject: Re: Release 6.6
>>>>>>> >>
>>>>>>> >> Martin -
>>>>>>> >>
>>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out as
>>>>>>> it uses some logging and APIs that aren’t already in the project and
>>>>>>> classpath of these lucene tests within that queries module (within
>>>>>>> IntelliJ, mind you).
>>>>>>> >>
>>>>>>> >> I was able to resolve the misunderstanding (and .equals/.hashCode
>>>>>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>>>>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>>>>>> working properly at a lower level?
>>>>>>> >>
>>>>>>> >> Erik
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>>>>> click the link below.
>>>>>>> >>>
>>>>>>> >>> TestPayloadCheckQuery.java
>>>>>>> >>> attached
>>>>>>> >>>
>>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>>> >>>
>>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>>> modification properly addresses your situation
>>>>>>> >>>
>>>>>>> >>> Thanks!
>>>>>>> >>> Martin
>>>>>>> >>> ______________________________________________
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>>> >>> To: dev@lucene.apache.org
>>>>>>> >>> Subject: Re: Release 6.6
>>>>>>> >>>
>>>>>>> >>> Martin - there is a test class specifically for this query.
>>>>>>>  See the recent commits I've made to test it further fixing
>>>>>>> .equals/.hashCode and rewrite.
>>>>>>> >>>
>>>>>>> >>> Can you send your full test code?
>>>>>>> >>>
>>>>>>> >>>    Erik
>>>>>>> >>>
>>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to
>>>>>>> work I was about to reply just run that TestCase
>>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>>> >>>>
>>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>>> >>>>   @org.junit.Test
>>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>> >>>>
>>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>>> construct query
>>>>>>> >>>>
>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 257 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> where postings="+postings);
>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 258 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> where position="+position);
>>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>>> 259 before query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> where term1="+term1);
>>>>>>> >>>>
>>>>>>> >>>>     try
>>>>>>> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>>> postings, int position,              //org.apache.lucene.index.Term term)
>>>>>>> throws java.io.IOException {
>>>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>>>>> lucene.index.Term)term1);
>>>>>>> >>>> }
>>>>>>> >>>> catch(java.io.IOException ioe) { log.error("
>>>>>>> TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>>>> >>>>
>>>>>>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>>>> >>>> Martin
>>>>>>> >>>> ______________________________________________
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>>> >>>> To: dev@lucene.apache.org
>>>>>>> >>>> Subject: Re: Release 6.6
>>>>>>> >>>>
>>>>>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>>>>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>>> >>>>
>>>>>>> >>>> Erik
>>>>>>> >>>>
>>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>>>>> wunder@wunderwood.org> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>> >>>>>
>>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>> >>>>>
>>>>>>> >>>>> wunder
>>>>>>> >>>>> Walter Underwood
>>>>>>> >>>>> wunder@wunderwood.org
>>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>> >>>>>>
>>>>>>> >>>>>> Hi,
>>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6.
>>>>>>> I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>>> before 7.0 release).
>>>>>>> >>>>>>
>>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>>> issues.
>>>>>>> >>>>>>
>>>>>>> >>>>>> What do you think?
>>>>>>> >>>>>>
>>>>>>> >>>>>> Regards,
>>>>>>> >>>>>> Ishan
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>

Re: Release 6.6

Posted by Adrien Grand <jp...@gmail.com>.
Sorry to hear that, make sure to take care of yourself first, the release
can wait! I just backported to branch_6_6.

Le mar. 16 mai 2017 à 19:22, Ishan Chattopadhyaya <ic...@gmail.com>
a écrit :

> Hi Adrien,
> Please proceed, by all means, to backport to release branch. I'm unwell
> today, and I haven't been able to start the RC cutting today; planning to
> do so after another 5-6 hours' rest.
> Thanks,
> Ishan
>
> On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com> wrote:
>
>> Hi Ishan,
>>
>> I don't think it is worth restarting RC build in case you already
>> started, but in case you haven't started yet,
>> https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to have
>> in 6.6.
>>
>> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> a écrit :
>>
>>> I attempted to build an RC, but failed repeatedly before realizing it
>>> was due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've
>>> manually cleared up the dead symlinks now. I'll build the RC on Tuesday, as
>>> I'm about to wrap up the day's work.
>>>
>>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>>
>>>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>>>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>>>> know if someone has any objections.
>>>>
>>>> Also, I'm planning to build the RC in another 3-4 hours. Please let me
>>>> know if there's something that someone is working on which needs to get in
>>>> before that.
>>>>
>>>> Thanks and regards,
>>>> Ishan
>>>>
>>>>
>>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>>
>>>>> Sure Steve! Thanks!
>>>>>
>>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com> wrote:
>>>>>
>>>>>> Ishan,
>>>>>>
>>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821
>>>>>> for 6.6?
>>>>>>
>>>>>> --
>>>>>> Steve
>>>>>> www.lucidworks.com
>>>>>>
>>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > Ok thanks Ishan.
>>>>>> >
>>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>> > Sure, Jim. Please go ahead!
>>>>>> >
>>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>> > Hi,
>>>>>> > Would be great to have
>>>>>> https://issues.apache.org/jira/browse/LUCENE-7824 included for 6.6.
>>>>>> Can I merge the fix this week end Ishan ?
>>>>>> >
>>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com>:
>>>>>> > Done, Adrien. Thanks!
>>>>>> >
>>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>>>> wrote:
>>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>>> well? I think it would help realize that the 6.6 branch has been cut when
>>>>>> looking at the CHANGES.txt file and not forget about backporting?
>>>>>> >
>>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>>>>> bugfixes to the branch, if needed.
>>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>>> there are any objections.
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Ishan
>>>>>> >
>>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>>> >
>>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>> > i was wondering if there was a specific test for
>>>>>> SpanPayloadCheckQuery method
>>>>>> >
>>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > the only implementation i could locate was in collectLeaf of
>>>>>> SpanPayloadCheckQuery
>>>>>> >
>>>>>> >
>>>>>> > I will submit JIRA with Patch
>>>>>> >
>>>>>> >
>>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>> implementations
>>>>>> >
>>>>>> >
>>>>>> > Can you suggest a book to read to better understand Lucenes pattern
>>>>>> dissection and match algorithms?
>>>>>> >
>>>>>> >
>>>>>> > Many Thanks for helpful guidance
>>>>>> > Martin
>>>>>> > ______________________________________________
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>>> >
>>>>>> > To: dev@lucene.apache.org
>>>>>> > Subject: Re: Release 6.6
>>>>>> >
>>>>>> > Martin -
>>>>>> >
>>>>>> > I have to admit to still being unsure what the gist is here - is
>>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>> now.
>>>>>> >
>>>>>> > I’m going to focus purely on SOLR-1485 this week to get it
>>>>>> committed for 6.6.  If there is an issue to address with your work would
>>>>>> you please open a JIRA and include your patch there?
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Erik
>>>>>> >
>>>>>> >
>>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Mornin' Erik
>>>>>> >>
>>>>>> >> there is a collectLeaf  override in
>>>>>> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:
>>>>>> >>
>>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>>> >>     @Override
>>>>>> >>     public void collectLeaf(PostingsEnum postings, int position,
>>>>>> Term term) throws IOException {
>>>>>> >>      ....
>>>>>> >>      }
>>>>>> >> }
>>>>>> >>
>>>>>> >> the modification in
>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf
>>>>>> for query
>>>>>> >>
>>>>>> >> //initialise term
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>> before term1=new org.apache.lucene.index.Term('field','withPayload')");
>>>>>> >> org.apache.lucene.index.Term term1=new
>>>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>> term1="+term1);
>>>>>> >>
>>>>>> >> //assume position is 5
>>>>>> >>     int position=5;
>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>> 235 position="+position);
>>>>>> >>
>>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>> 237 pay="+pay);
>>>>>> >>
>>>>>> >> //build spanQuery with term parameter
>>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>> SpanTermQuery(term1);
>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>> 239 spanQuery1="+spanQuery1);
>>>>>> >>
>>>>>> >> //add BytesRef to payloadToMatch list
>>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>> payloadToMatch=new java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>> 241 payloadToMatch="+payloadToMatch);
>>>>>> >>     payloadToMatch.add(pay);
>>>>>> >>
>>>>>> >> //build SpanPayloadCheckQuery
>>>>>> >> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>> query="+query);
>>>>>> >>
>>>>>> >> //build lucene Directory (TODO: we should use an existing
>>>>>> directory with REAL test-data)
>>>>>> >> org.apache.lucene.store.Directory ram =
>>>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>>>>> >>
>>>>>> >> //build SegmentReader from Directory
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>> ram="+ram);
>>>>>> >> SegmentReader reader =
>>>>>> getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>> reader="+reader);
>>>>>> >>
>>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>>> 255 sr="+sr);
>>>>>> >>
>>>>>> >> //add term to SegmentReader postings
>>>>>> >> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>>>>> PostingsEnum.PAYLOADS);
>>>>>> >>
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>> before
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> postings="+postings);
>>>>>> >>
>>>>>> >> //display the parameters for collectLeaf method for query:
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>> before
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> position="+position);
>>>>>> >>
>>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>> before
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>> >>     try
>>>>>> >>     { //public void
>>>>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>    //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>> >>
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>> >> }
>>>>>> >> catch(java.io.IOException ioe) {
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>> IOException ="+ioe.getMessage()); }
>>>>>> >>
>>>>>> >> collectLeaf is the only method that compares
>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>> >> to determine "match"
>>>>>> >>
>>>>>> >> unless of course match between individual payload and
>>>>>> payloadToMatch is tested elsewhere ?
>>>>>> >>
>>>>>> >> WDYT?
>>>>>> >> Martin
>>>>>> >> ______________________________________________
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>>> >> To: Lucene/Solr dev
>>>>>> >> Subject: Re: Release 6.6
>>>>>> >>
>>>>>> >> Martin -
>>>>>> >>
>>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out as
>>>>>> it uses some logging and APIs that aren’t already in the project and
>>>>>> classpath of these lucene tests within that queries module (within
>>>>>> IntelliJ, mind you).
>>>>>> >>
>>>>>> >> I was able to resolve the misunderstanding (and .equals/.hashCode
>>>>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>>>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>>>>> working properly at a lower level?
>>>>>> >>
>>>>>> >> Erik
>>>>>> >>
>>>>>> >>
>>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>>>> click the link below.
>>>>>> >>>
>>>>>> >>> TestPayloadCheckQuery.java
>>>>>> >>> attached
>>>>>> >>>
>>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>>> >>>
>>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>>> modification properly addresses your situation
>>>>>> >>>
>>>>>> >>> Thanks!
>>>>>> >>> Martin
>>>>>> >>> ______________________________________________
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>>> >>> To: dev@lucene.apache.org
>>>>>> >>> Subject: Re: Release 6.6
>>>>>> >>>
>>>>>> >>> Martin - there is a test class specifically for this query.   See
>>>>>> the recent commits I've made to test it further fixing .equals/.hashCode
>>>>>> and rewrite.
>>>>>> >>>
>>>>>> >>> Can you send your full test code?
>>>>>> >>>
>>>>>> >>>    Erik
>>>>>> >>>
>>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work
>>>>>> I was about to reply just run that TestCase
>>>>>> >>>> (until i discovered there wasnt any!)
>>>>>> >>>>
>>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>>> >>>>   @org.junit.Test
>>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>>> >>>>
>>>>>> >>>>     //now lets test the collectLeaf for query
>>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>>> construct query
>>>>>> >>>>
>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>> before
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> postings="+postings);
>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>> before
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> position="+position);
>>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>> before
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>>>> >>>>
>>>>>> >>>>     try
>>>>>> >>>>     { //test public void
>>>>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>>>           //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>>>> >>>>
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>> >>>> }
>>>>>> >>>> catch(java.io.IOException ioe) {
>>>>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>> IOException ="+ioe.getMessage()); }
>>>>>> >>>>
>>>>>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>>> >>>> Martin
>>>>>> >>>> ______________________________________________
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>>> >>>> To: dev@lucene.apache.org
>>>>>> >>>> Subject: Re: Release 6.6
>>>>>> >>>>
>>>>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>>>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>> >>>>
>>>>>> >>>> Erik
>>>>>> >>>>
>>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>>>> wunder@wunderwood.org> wrote:
>>>>>> >>>>>
>>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>> >>>>>
>>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>> >>>>>
>>>>>> >>>>> wunder
>>>>>> >>>>> Walter Underwood
>>>>>> >>>>> wunder@wunderwood.org
>>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>> Hi,
>>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd
>>>>>> like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>>> before 7.0 release).
>>>>>> >>>>>>
>>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>>> issues.
>>>>>> >>>>>>
>>>>>> >>>>>> What do you think?
>>>>>> >>>>>>
>>>>>> >>>>>> Regards,
>>>>>> >>>>>> Ishan
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Hi Adrien,
Please proceed, by all means, to backport to release branch. I'm unwell
today, and I haven't been able to start the RC cutting today; planning to
do so after another 5-6 hours' rest.
Thanks,
Ishan

On Tue, May 16, 2017 at 10:06 PM, Adrien Grand <jp...@gmail.com> wrote:

> Hi Ishan,
>
> I don't think it is worth restarting RC build in case you already started,
> but in case you haven't started yet, https://issues.apache.org/
> jira/browse/LUCENE-7831 could be nice to have in 6.6.
>
> Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> a écrit :
>
>> I attempted to build an RC, but failed repeatedly before realizing it was
>> due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've manually
>> cleared up the dead symlinks now. I'll build the RC on Tuesday, as I'm
>> about to wrap up the day's work.
>>
>> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>>> know if someone has any objections.
>>>
>>> Also, I'm planning to build the RC in another 3-4 hours. Please let me
>>> know if there's something that someone is working on which needs to get in
>>> before that.
>>>
>>> Thanks and regards,
>>> Ishan
>>>
>>>
>>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>>
>>>> Sure Steve! Thanks!
>>>>
>>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com> wrote:
>>>>
>>>>> Ishan,
>>>>>
>>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 for
>>>>> 6.6?
>>>>>
>>>>> --
>>>>> Steve
>>>>> www.lucidworks.com
>>>>>
>>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Ok thanks Ishan.
>>>>> >
>>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>> > Sure, Jim. Please go ahead!
>>>>> >
>>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>>> jim.ferenczi@gmail.com> wrote:
>>>>> > Hi,
>>>>> > Would be great to have https://issues.apache.org/
>>>>> jira/browse/LUCENE-7824 included for 6.6. Can I merge the fix this
>>>>> week end Ishan ?
>>>>> >
>>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com>:
>>>>> > Done, Adrien. Thanks!
>>>>> >
>>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>>> wrote:
>>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as
>>>>> well? I think it would help realize that the 6.6 branch has been cut when
>>>>> looking at the CHANGES.txt file and not forget about backporting?
>>>>> >
>>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> a écrit :
>>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>>>> bugfixes to the branch, if needed.
>>>>> > Planning to build the first RC on 15 May. Please let me know if
>>>>> there are any objections.
>>>>> >
>>>>> > Thanks,
>>>>> > Ishan
>>>>> >
>>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> > Planning to cut the release branch in another 10-12 hours.
>>>>> >
>>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>> > i was wondering if there was a specific test for
>>>>> SpanPayloadCheckQuery method
>>>>> >
>>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>> >
>>>>> >
>>>>> >
>>>>> > the only implementation i could locate was in collectLeaf of
>>>>> SpanPayloadCheckQuery
>>>>> >
>>>>> >
>>>>> > I will submit JIRA with Patch
>>>>> >
>>>>> >
>>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>> implementations
>>>>> >
>>>>> >
>>>>> > Can you suggest a book to read to better understand Lucenes pattern
>>>>> dissection and match algorithms?
>>>>> >
>>>>> >
>>>>> > Many Thanks for helpful guidance
>>>>> > Martin
>>>>> > ______________________________________________
>>>>> >
>>>>> >
>>>>> >
>>>>> > From: Erik Hatcher <er...@gmail.com>
>>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>>> >
>>>>> > To: dev@lucene.apache.org
>>>>> > Subject: Re: Release 6.6
>>>>> >
>>>>> > Martin -
>>>>> >
>>>>> > I have to admit to still being unsure what the gist is here - is
>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>> now.
>>>>> >
>>>>> > I’m going to focus purely on SOLR-1485 this week to get it committed
>>>>> for 6.6.  If there is an issue to address with your work would you please
>>>>> open a JIRA and include your patch there?
>>>>> >
>>>>> > Thanks,
>>>>> > Erik
>>>>> >
>>>>> >
>>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Mornin' Erik
>>>>> >>
>>>>> >> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans
>>>>> ..but its never called:
>>>>> >>
>>>>> >> static class VerifyingCollector implements SpanCollector {
>>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>>> >>     @Override
>>>>> >>     public void collectLeaf(PostingsEnum postings, int position,
>>>>> Term term) throws IOException {
>>>>> >>      ....
>>>>> >>      }
>>>>> >> }
>>>>> >>
>>>>> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>>>>> tests collectLeaf for query
>>>>> >>
>>>>> >> //initialise term
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>> before term1=new org.apache.lucene.index.Term('
>>>>> field','withPayload')");
>>>>> >> org.apache.lucene.index.Term term1=new
>>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>> term1="+term1);
>>>>> >>
>>>>> >> //assume position is 5
>>>>> >>     int position=5;
>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>> 235 position="+position);
>>>>> >>
>>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>> 237 pay="+pay);
>>>>> >>
>>>>> >> //build spanQuery with term parameter
>>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>> SpanTermQuery(term1);
>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>> 239 spanQuery1="+spanQuery1);
>>>>> >>
>>>>> >> //add BytesRef to payloadToMatch list
>>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>> payloadToMatch=new java.util.ArrayList<org.
>>>>> apache.lucene.util.BytesRef>();
>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>> 241 payloadToMatch="+payloadToMatch);
>>>>> >>     payloadToMatch.add(pay);
>>>>> >>
>>>>> >> //build SpanPayloadCheckQuery
>>>>> >> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>> query="+query);
>>>>> >>
>>>>> >> //build lucene Directory (TODO: we should use an existing directory
>>>>> with REAL test-data)
>>>>> >> org.apache.lucene.store.Directory ram =
>>>>> newDirectory(com.carrotsearch.randomizedtesting.
>>>>> RandomizedContext.current().getRandom());
>>>>> >>
>>>>> >> //build SegmentReader from Directory
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>> ram="+ram);
>>>>> >> SegmentReader reader = getOnlySegmentReader(org.
>>>>> apache.lucene.index.DirectoryReader.open(ram));
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>> reader="+reader);
>>>>> >>
>>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE
>>>>> 255 sr="+sr);
>>>>> >>
>>>>> >> //add term to SegmentReader postings
>>>>> >> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>>>> PostingsEnum.PAYLOADS);
>>>>> >>
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> where postings="+postings);
>>>>> >>
>>>>> >> //display the parameters for collectLeaf method for query:
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> where position="+position);
>>>>> >>
>>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> where term1="+term1);
>>>>> >>     try
>>>>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>> postings, int position,       //org.apache.lucene.index.Term term)
>>>>> throws java.io.IOException {
>>>>> >> query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>>> lucene.index.Term)term1);
>>>>> >> }
>>>>> >> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>> >>
>>>>> >> collectLeaf is the only method that compares
>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>> >> to determine "match"
>>>>> >>
>>>>> >> unless of course match between individual payload and
>>>>> payloadToMatch is tested elsewhere ?
>>>>> >>
>>>>> >> WDYT?
>>>>> >> Martin
>>>>> >> ______________________________________________
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>>> >> To: Lucene/Solr dev
>>>>> >> Subject: Re: Release 6.6
>>>>> >>
>>>>> >> Martin -
>>>>> >>
>>>>> >> Interesting test but I couldn’t copy/paste it in to try it out as
>>>>> it uses some logging and APIs that aren’t already in the project and
>>>>> classpath of these lucene tests within that queries module (within
>>>>> IntelliJ, mind you).
>>>>> >>
>>>>> >> I was able to resolve the misunderstanding (and .equals/.hashCode
>>>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>>>> working properly at a lower level?
>>>>> >>
>>>>> >> Erik
>>>>> >>
>>>>> >>
>>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>>> click the link below.
>>>>> >>>
>>>>> >>> TestPayloadCheckQuery.java
>>>>> >>> attached
>>>>> >>>
>>>>> >>> I coded this last nite so it is "quick and dirty"
>>>>> >>>
>>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>>> modification properly addresses your situation
>>>>> >>>
>>>>> >>> Thanks!
>>>>> >>> Martin
>>>>> >>> ______________________________________________
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>>> >>> To: dev@lucene.apache.org
>>>>> >>> Subject: Re: Release 6.6
>>>>> >>>
>>>>> >>> Martin - there is a test class specifically for this query.   See
>>>>> the recent commits I've made to test it further fixing .equals/.hashCode
>>>>> and rewrite.
>>>>> >>>
>>>>> >>> Can you send your full test code?
>>>>> >>>
>>>>> >>>    Erik
>>>>> >>>
>>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work
>>>>> I was about to reply just run that TestCase
>>>>> >>>> (until i discovered there wasnt any!)
>>>>> >>>>
>>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>> >>>>   @org.junit.Test
>>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>>> >>>>
>>>>> >>>>     //now lets test the collectLeaf for query
>>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>>> construct query
>>>>> >>>>
>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> where postings="+postings);
>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> where position="+position);
>>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> where term1="+term1);
>>>>> >>>>
>>>>> >>>>     try
>>>>> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>> postings, int position,              //org.apache.lucene.index.Term term)
>>>>> throws java.io.IOException {
>>>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>>> lucene.index.Term)term1);
>>>>> >>>> }
>>>>> >>>> catch(java.io.IOException ioe) { log.error("
>>>>> TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>> >>>>
>>>>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>> >>>> Martin
>>>>> >>>> ______________________________________________
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>>> >>>> To: dev@lucene.apache.org
>>>>> >>>> Subject: Re: Release 6.6
>>>>> >>>>
>>>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>> >>>>
>>>>> >>>> Erik
>>>>> >>>>
>>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>>> wunder@wunderwood.org> wrote:
>>>>> >>>>>
>>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>>> >>>>>
>>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>> >>>>>
>>>>> >>>>> wunder
>>>>> >>>>> Walter Underwood
>>>>> >>>>> wunder@wunderwood.org
>>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Hi,
>>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd
>>>>> like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>>> before 7.0 release).
>>>>> >>>>>>
>>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>>> branch around 4th May, in order to let some time for devs to finish current
>>>>> issues.
>>>>> >>>>>>
>>>>> >>>>>> What do you think?
>>>>> >>>>>>
>>>>> >>>>>> Regards,
>>>>> >>>>>> Ishan
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>
>>>
>>

Re: Release 6.6

Posted by Adrien Grand <jp...@gmail.com>.
Hi Ishan,

I don't think it is worth restarting RC build in case you already started,
but in case you haven't started yet,
https://issues.apache.org/jira/browse/LUCENE-7831 could be nice to have in
6.6.

Le mar. 16 mai 2017 à 03:55, Ishan Chattopadhyaya <ic...@gmail.com>
a écrit :

> I attempted to build an RC, but failed repeatedly before realizing it was
> due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've manually
> cleared up the dead symlinks now. I'll build the RC on Tuesday, as I'm
> about to wrap up the day's work.
>
> On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> I wish to backport a fix from SOLR-8440 (last commit) to the release
>> branch. It affects only the feature introduced in SOLR-8440. Please let me
>> know if someone has any objections.
>>
>> Also, I'm planning to build the RC in another 3-4 hours. Please let me
>> know if there's something that someone is working on which needs to get in
>> before that.
>>
>> Thanks and regards,
>> Ishan
>>
>>
>> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> Sure Steve! Thanks!
>>>
>>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com> wrote:
>>>
>>>> Ishan,
>>>>
>>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 for
>>>> 6.6?
>>>>
>>>> --
>>>> Steve
>>>> www.lucidworks.com
>>>>
>>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Ok thanks Ishan.
>>>> >
>>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>>> ichattopadhyaya@gmail.com> a écrit :
>>>> > Sure, Jim. Please go ahead!
>>>> >
>>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <
>>>> jim.ferenczi@gmail.com> wrote:
>>>> > Hi,
>>>> > Would be great to have
>>>> https://issues.apache.org/jira/browse/LUCENE-7824 included for 6.6.
>>>> Can I merge the fix this week end Ishan ?
>>>> >
>>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com>:
>>>> > Done, Adrien. Thanks!
>>>> >
>>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>>> wrote:
>>>> > Ishan, wdyt about running addVersion on the branch_6x/master as well?
>>>> I think it would help realize that the 6.6 branch has been cut when looking
>>>> at the CHANGES.txt file and not forget about backporting?
>>>> >
>>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> a écrit :
>>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>>> bugfixes to the branch, if needed.
>>>> > Planning to build the first RC on 15 May. Please let me know if there
>>>> are any objections.
>>>> >
>>>> > Thanks,
>>>> > Ishan
>>>> >
>>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> > Planning to cut the release branch in another 10-12 hours.
>>>> >
>>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>>> wrote:
>>>> > i was wondering if there was a specific test for
>>>> SpanPayloadCheckQuery method
>>>> >
>>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>> >
>>>> >
>>>> >
>>>> > the only implementation i could locate was in collectLeaf of
>>>> SpanPayloadCheckQuery
>>>> >
>>>> >
>>>> > I will submit JIRA with Patch
>>>> >
>>>> >
>>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>> sentence fragments (what we called phenomes) than current SEO
>>>> implementations
>>>> >
>>>> >
>>>> > Can you suggest a book to read to better understand Lucenes pattern
>>>> dissection and match algorithms?
>>>> >
>>>> >
>>>> > Many Thanks for helpful guidance
>>>> > Martin
>>>> > ______________________________________________
>>>> >
>>>> >
>>>> >
>>>> > From: Erik Hatcher <er...@gmail.com>
>>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>>> >
>>>> > To: dev@lucene.apache.org
>>>> > Subject: Re: Release 6.6
>>>> >
>>>> > Martin -
>>>> >
>>>> > I have to admit to still being unsure what the gist is here - is
>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>> now.
>>>> >
>>>> > I’m going to focus purely on SOLR-1485 this week to get it committed
>>>> for 6.6.  If there is an issue to address with your work would you please
>>>> open a JIRA and include your patch there?
>>>> >
>>>> > Thanks,
>>>> > Erik
>>>> >
>>>> >
>>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>> wrote:
>>>> >>
>>>> >> Mornin' Erik
>>>> >>
>>>> >> there is a collectLeaf  override in
>>>> org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:
>>>> >>
>>>> >> static class VerifyingCollector implements SpanCollector {
>>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>>> >>     @Override
>>>> >>     public void collectLeaf(PostingsEnum postings, int position,
>>>> Term term) throws IOException {
>>>> >>      ....
>>>> >>      }
>>>> >> }
>>>> >>
>>>> >> the modification in
>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf
>>>> for query
>>>> >>
>>>> >> //initialise term
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>> before term1=new org.apache.lucene.index.Term('field','withPayload')");
>>>> >> org.apache.lucene.index.Term term1=new
>>>> org.apache.lucene.index.Term("field", "withPayload");
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>> term1="+term1);
>>>> >>
>>>> >> //assume position is 5
>>>> >>     int position=5;
>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>>> position="+position);
>>>> >>
>>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>>> pay="+pay);
>>>> >>
>>>> >> //build spanQuery with term parameter
>>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>> SpanTermQuery(term1);
>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>>> spanQuery1="+spanQuery1);
>>>> >>
>>>> >> //add BytesRef to payloadToMatch list
>>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>>> payloadToMatch=new java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>>> payloadToMatch="+payloadToMatch);
>>>> >>     payloadToMatch.add(pay);
>>>> >>
>>>> >> //build SpanPayloadCheckQuery
>>>> >> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>> query="+query);
>>>> >>
>>>> >> //build lucene Directory (TODO: we should use an existing directory
>>>> with REAL test-data)
>>>> >> org.apache.lucene.store.Directory ram =
>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>>> >>
>>>> >> //build SegmentReader from Directory
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>> ram="+ram);
>>>> >> SegmentReader reader =
>>>> getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>> reader="+reader);
>>>> >>
>>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>>> >>     org.apache.lucene.index.LeafReader sr =
>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>>>> sr="+sr);
>>>> >>
>>>> >> //add term to SegmentReader postings
>>>> >> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>>> PostingsEnum.PAYLOADS);
>>>> >>
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>> before
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>> postings="+postings);
>>>> >>
>>>> >> //display the parameters for collectLeaf method for query:
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>> before
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>> position="+position);
>>>> >>
>>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>> before
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>> >>     try
>>>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>> postings, int position,       //org.apache.lucene.index.Term term) throws
>>>> java.io.IOException {
>>>> >>
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>> >> }
>>>> >> catch(java.io.IOException ioe) {
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>> IOException ="+ioe.getMessage()); }
>>>> >>
>>>> >> collectLeaf is the only method that compares
>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>> >> to determine "match"
>>>> >>
>>>> >> unless of course match between individual payload and payloadToMatch
>>>> is tested elsewhere ?
>>>> >>
>>>> >> WDYT?
>>>> >> Martin
>>>> >> ______________________________________________
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Erik Hatcher <er...@gmail.com>
>>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>>> >> To: Lucene/Solr dev
>>>> >> Subject: Re: Release 6.6
>>>> >>
>>>> >> Martin -
>>>> >>
>>>> >> Interesting test but I couldn’t copy/paste it in to try it out as it
>>>> uses some logging and APIs that aren’t already in the project and classpath
>>>> of these lucene tests within that queries module (within IntelliJ, mind
>>>> you).
>>>> >>
>>>> >> I was able to resolve the misunderstanding (and .equals/.hashCode
>>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>>> working properly at a lower level?
>>>> >>
>>>> >> Erik
>>>> >>
>>>> >>
>>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Martin Gainty has shared a OneDrive file with you. To view it,
>>>> click the link below.
>>>> >>>
>>>> >>> TestPayloadCheckQuery.java
>>>> >>> attached
>>>> >>>
>>>> >>> I coded this last nite so it is "quick and dirty"
>>>> >>>
>>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>>> modification properly addresses your situation
>>>> >>>
>>>> >>> Thanks!
>>>> >>> Martin
>>>> >>> ______________________________________________
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> From: Erik Hatcher <er...@gmail.com>
>>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>>> >>> To: dev@lucene.apache.org
>>>> >>> Subject: Re: Release 6.6
>>>> >>>
>>>> >>> Martin - there is a test class specifically for this query.   See
>>>> the recent commits I've made to test it further fixing .equals/.hashCode
>>>> and rewrite.
>>>> >>>
>>>> >>> Can you send your full test code?
>>>> >>>
>>>> >>>    Erik
>>>> >>>
>>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>>> wrote:
>>>> >>>
>>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
>>>> was about to reply just run that TestCase
>>>> >>>> (until i discovered there wasnt any!)
>>>> >>>>
>>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>> >>>>   @org.junit.Test
>>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>>> >>>>
>>>> >>>>     //now lets test the collectLeaf for query
>>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>>> construct query
>>>> >>>>
>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>> before
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>> postings="+postings);
>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>> before
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>> position="+position);
>>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>> before
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>> >>>>
>>>> >>>>     try
>>>> >>>>     { //test public void
>>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>>           //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>> >>>>
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>> >>>> }
>>>> >>>> catch(java.io.IOException ioe) {
>>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>> IOException ="+ioe.getMessage()); }
>>>> >>>>
>>>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>>>> >>>> Martin
>>>> >>>> ______________________________________________
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>> >>>> To: dev@lucene.apache.org
>>>> >>>> Subject: Re: Release 6.6
>>>> >>>>
>>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>> >>>>
>>>> >>>> Erik
>>>> >>>>
>>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>>> wunder@wunderwood.org> wrote:
>>>> >>>>>
>>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>>> >>>>>
>>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>> >>>>>
>>>> >>>>> wunder
>>>> >>>>> Walter Underwood
>>>> >>>>> wunder@wunderwood.org
>>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>> >>>>>>
>>>> >>>>>> Hi,
>>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd
>>>> like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>>> before 7.0 release).
>>>> >>>>>>
>>>> >>>>>> I can volunteer to release this, and I can cut the release
>>>> branch around 4th May, in order to let some time for devs to finish current
>>>> issues.
>>>> >>>>>>
>>>> >>>>>> What do you think?
>>>> >>>>>>
>>>> >>>>>> Regards,
>>>> >>>>>> Ishan
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>>>
>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
I attempted to build an RC, but failed repeatedly before realizing it was
due to, apart from test failures, LUCENE-7830 / LUCENE-6438. I've manually
cleared up the dead symlinks now. I'll build the RC on Tuesday, as I'm
about to wrap up the day's work.

On Mon, May 15, 2017 at 10:12 PM, Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> I wish to backport a fix from SOLR-8440 (last commit) to the release
> branch. It affects only the feature introduced in SOLR-8440. Please let me
> know if someone has any objections.
>
> Also, I'm planning to build the RC in another 3-4 hours. Please let me
> know if there's something that someone is working on which needs to get in
> before that.
>
> Thanks and regards,
> Ishan
>
>
> On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> Sure Steve! Thanks!
>>
>> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com> wrote:
>>
>>> Ishan,
>>>
>>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 for
>>> 6.6?
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>> > On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
>>> wrote:
>>> >
>>> > Ok thanks Ishan.
>>> >
>>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <
>>> ichattopadhyaya@gmail.com> a écrit :
>>> > Sure, Jim. Please go ahead!
>>> >
>>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <ji...@gmail.com>
>>> wrote:
>>> > Hi,
>>> > Would be great to have https://issues.apache.org/jira
>>> /browse/LUCENE-7824 included for 6.6. Can I merge the fix this week end
>>> Ishan ?
>>> >
>>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com>:
>>> > Done, Adrien. Thanks!
>>> >
>>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>>> wrote:
>>> > Ishan, wdyt about running addVersion on the branch_6x/master as well?
>>> I think it would help realize that the 6.6 branch has been cut when looking
>>> at the CHANGES.txt file and not forget about backporting?
>>> >
>>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> a écrit :
>>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>> bugfixes to the branch, if needed.
>>> > Planning to build the first RC on 15 May. Please let me know if there
>>> are any objections.
>>> >
>>> > Thanks,
>>> > Ishan
>>> >
>>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> > Planning to cut the release branch in another 10-12 hours.
>>> >
>>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>> wrote:
>>> > i was wondering if there was a specific test for SpanPayloadCheckQuery
>>> method
>>> >
>>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>>> >
>>> >
>>> >
>>> > the only implementation i could locate was in collectLeaf of
>>> SpanPayloadCheckQuery
>>> >
>>> >
>>> > I will submit JIRA with Patch
>>> >
>>> >
>>> > as a CS *dinosaur* I am more familiar with LISP for dissecting
>>> sentence fragments (what we called phenomes) than current SEO
>>> implementations
>>> >
>>> >
>>> > Can you suggest a book to read to better understand Lucenes pattern
>>> dissection and match algorithms?
>>> >
>>> >
>>> > Many Thanks for helpful guidance
>>> > Martin
>>> > ______________________________________________
>>> >
>>> >
>>> >
>>> > From: Erik Hatcher <er...@gmail.com>
>>> > Sent: Sunday, April 30, 2017 2:06 PM
>>> >
>>> > To: dev@lucene.apache.org
>>> > Subject: Re: Release 6.6
>>> >
>>> > Martin -
>>> >
>>> > I have to admit to still being unsure what the gist is here - is there
>>> a bug?   Apologies for not catching what you’re saying/showing here.
>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>> now.
>>> >
>>> > I’m going to focus purely on SOLR-1485 this week to get it committed
>>> for 6.6.  If there is an issue to address with your work would you please
>>> open a JIRA and include your patch there?
>>> >
>>> > Thanks,
>>> > Erik
>>> >
>>> >
>>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>> wrote:
>>> >>
>>> >> Mornin' Erik
>>> >>
>>> >> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans
>>> ..but its never called:
>>> >>
>>> >> static class VerifyingCollector implements SpanCollector {
>>> >>     List<BytesRef> payloads = new ArrayList<>();
>>> >>     @Override
>>> >>     public void collectLeaf(PostingsEnum postings, int position, Term
>>> term) throws IOException {
>>> >>      ....
>>> >>      }
>>> >> }
>>> >>
>>> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>>> tests collectLeaf for query
>>> >>
>>> >> //initialise term
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>> before term1=new org.apache.lucene.index.Term('field','withPayload')");
>>> >> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
>>> "withPayload");
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>> term1="+term1);
>>> >>
>>> >> //assume position is 5
>>> >>     int position=5;
>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>> position="+position);
>>> >>
>>> >>     BytesRef pay = new BytesRef("pos: " + position);
>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>> pay="+pay);
>>> >>
>>> >> //build spanQuery with term parameter
>>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>> SpanTermQuery(term1);
>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>> spanQuery1="+spanQuery1);
>>> >>
>>> >> //add BytesRef to payloadToMatch list
>>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>>> payloadToMatch=new java.util.ArrayList<org.apache
>>> .lucene.util.BytesRef>();
>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>> payloadToMatch="+payloadToMatch);
>>> >>     payloadToMatch.add(pay);
>>> >>
>>> >> //build SpanPayloadCheckQuery
>>> >> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>> query="+query);
>>> >>
>>> >> //build lucene Directory (TODO: we should use an existing directory
>>> with REAL test-data)
>>> >> org.apache.lucene.store.Directory ram =
>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedCo
>>> ntext.current().getRandom());
>>> >>
>>> >> //build SegmentReader from Directory
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>> ram="+ram);
>>> >> SegmentReader reader = getOnlySegmentReader(org.apach
>>> e.lucene.index.DirectoryReader.open(ram));
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>> reader="+reader);
>>> >>
>>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>>> >>     org.apache.lucene.index.LeafReader sr =
>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>>> sr="+sr);
>>> >>
>>> >> //add term to SegmentReader postings
>>> >> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>> PostingsEnum.PAYLOADS);
>>> >>
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> postings="+postings);
>>> >>
>>> >> //display the parameters for collectLeaf method for query:
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> position="+position);
>>> >>
>>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>> >>     try
>>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>> postings, int position,       //org.apache.lucene.index.Term term)
>>> throws java.io.IOException {
>>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1);
>>> >> }
>>> >> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>> IOException ="+ioe.getMessage()); }
>>> >>
>>> >> collectLeaf is the only method that compares
>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>> >> to determine "match"
>>> >>
>>> >> unless of course match between individual payload and payloadToMatch
>>> is tested elsewhere ?
>>> >>
>>> >> WDYT?
>>> >> Martin
>>> >> ______________________________________________
>>> >>
>>> >>
>>> >>
>>> >> From: Erik Hatcher <er...@gmail.com>
>>> >> Sent: Saturday, April 29, 2017 7:58 PM
>>> >> To: Lucene/Solr dev
>>> >> Subject: Re: Release 6.6
>>> >>
>>> >> Martin -
>>> >>
>>> >> Interesting test but I couldn’t copy/paste it in to try it out as it
>>> uses some logging and APIs that aren’t already in the project and classpath
>>> of these lucene tests within that queries module (within IntelliJ, mind
>>> you).
>>> >>
>>> >> I was able to resolve the misunderstanding (and .equals/.hashCode
>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>> working properly at a lower level?
>>> >>
>>> >> Erik
>>> >>
>>> >>
>>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>> wrote:
>>> >>>
>>> >>> Martin Gainty has shared a OneDrive file with you. To view it, click
>>> the link below.
>>> >>>
>>> >>> TestPayloadCheckQuery.java
>>> >>> attached
>>> >>>
>>> >>> I coded this last nite so it is "quick and dirty"
>>> >>>
>>> >>> in any case let me know if  testSpanPayloadCheck() method
>>> modification properly addresses your situation
>>> >>>
>>> >>> Thanks!
>>> >>> Martin
>>> >>> ______________________________________________
>>> >>>
>>> >>>
>>> >>>
>>> >>> From: Erik Hatcher <er...@gmail.com>
>>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>>> >>> To: dev@lucene.apache.org
>>> >>> Subject: Re: Release 6.6
>>> >>>
>>> >>> Martin - there is a test class specifically for this query.   See
>>> the recent commits I've made to test it further fixing .equals/.hashCode
>>> and rewrite.
>>> >>>
>>> >>> Can you send your full test code?
>>> >>>
>>> >>>    Erik
>>> >>>
>>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com>
>>> wrote:
>>> >>>
>>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
>>> was about to reply just run that TestCase
>>> >>>> (until i discovered there wasnt any!)
>>> >>>>
>>> >>>> i'll start the bidding at 1 dinar for TestCase
>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>> >>>>   @org.junit.Test
>>> >>>>   public void testSpanPayloadCheck() throws Exception
>>> >>>>
>>> >>>>     //now lets test the collectLeaf for query
>>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>>> construct query
>>> >>>>
>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> postings="+postings);
>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> position="+position);
>>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>> >>>>
>>> >>>>     try
>>> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>> postings, int position,              //org.apache.lucene.index.Term term)
>>> throws java.io.IOException {
>>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1);
>>> >>>> }
>>> >>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>> IOException ="+ioe.getMessage()); }
>>> >>>>
>>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>>> >>>> Martin
>>> >>>> ______________________________________________
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> From: Erik Hatcher <er...@gmail.com>
>>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>> >>>> To: dev@lucene.apache.org
>>> >>>> Subject: Re: Release 6.6
>>> >>>>
>>> >>>> Probably no bribe needed, but an updated patch would be a good
>>> start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>> >>>>
>>> >>>> Erik
>>> >>>>
>>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>>> wunder@wunderwood.org> wrote:
>>> >>>>>
>>> >>>>> Who do I have to bribe to get SOLR-629 included?
>>> >>>>>
>>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>>> >>>>>
>>> >>>>> wunder
>>> >>>>> Walter Underwood
>>> >>>>> wunder@wunderwood.org
>>> >>>>> http://observer.wunderwood.org/  (my blog)
>>> >>>>>
>>> >>>>>
>>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>> >>>>>>
>>> >>>>>> Hi,
>>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd
>>> like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>>> before 7.0 release).
>>> >>>>>>
>>> >>>>>> I can volunteer to release this, and I can cut the release branch
>>> around 4th May, in order to let some time for devs to finish current issues.
>>> >>>>>>
>>> >>>>>> What do you think?
>>> >>>>>>
>>> >>>>>> Regards,
>>> >>>>>> Ishan
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
I wish to backport a fix from SOLR-8440 (last commit) to the release
branch. It affects only the feature introduced in SOLR-8440. Please let me
know if someone has any objections.

Also, I'm planning to build the RC in another 3-4 hours. Please let me know
if there's something that someone is working on which needs to get in
before that.

Thanks and regards,
Ishan


On Sun, May 14, 2017 at 5:02 PM, Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> Sure Steve! Thanks!
>
> On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com> wrote:
>
>> Ishan,
>>
>> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 for
>> 6.6?
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
>> wrote:
>> >
>> > Ok thanks Ishan.
>> >
>> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <ic...@gmail.com>
>> a écrit :
>> > Sure, Jim. Please go ahead!
>> >
>> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <ji...@gmail.com>
>> wrote:
>> > Hi,
>> > Would be great to have https://issues.apache.org/jira
>> /browse/LUCENE-7824 included for 6.6. Can I merge the fix this week end
>> Ishan ?
>> >
>> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com>:
>> > Done, Adrien. Thanks!
>> >
>> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com>
>> wrote:
>> > Ishan, wdyt about running addVersion on the branch_6x/master as well? I
>> think it would help realize that the 6.6 branch has been cut when looking
>> at the CHANGES.txt file and not forget about backporting?
>> >
>> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> a écrit :
>> > I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>> bugfixes to the branch, if needed.
>> > Planning to build the first RC on 15 May. Please let me know if there
>> are any objections.
>> >
>> > Thanks,
>> > Ishan
>> >
>> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> > Planning to cut the release branch in another 10-12 hours.
>> >
>> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>> wrote:
>> > i was wondering if there was a specific test for SpanPayloadCheckQuery
>> method
>> >
>> > matches = payloadToMatch.get(upto).bytesEquals(payload);
>> >
>> >
>> >
>> > the only implementation i could locate was in collectLeaf of
>> SpanPayloadCheckQuery
>> >
>> >
>> > I will submit JIRA with Patch
>> >
>> >
>> > as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
>> fragments (what we called phenomes) than current SEO implementations
>> >
>> >
>> > Can you suggest a book to read to better understand Lucenes pattern
>> dissection and match algorithms?
>> >
>> >
>> > Many Thanks for helpful guidance
>> > Martin
>> > ______________________________________________
>> >
>> >
>> >
>> > From: Erik Hatcher <er...@gmail.com>
>> > Sent: Sunday, April 30, 2017 2:06 PM
>> >
>> > To: dev@lucene.apache.org
>> > Subject: Re: Release 6.6
>> >
>> > Martin -
>> >
>> > I have to admit to still being unsure what the gist is here - is there
>> a bug?   Apologies for not catching what you’re saying/showing here.
>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>> now.
>> >
>> > I’m going to focus purely on SOLR-1485 this week to get it committed
>> for 6.6.  If there is an issue to address with your work would you please
>> open a JIRA and include your patch there?
>> >
>> > Thanks,
>> > Erik
>> >
>> >
>> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>> wrote:
>> >>
>> >> Mornin' Erik
>> >>
>> >> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans
>> ..but its never called:
>> >>
>> >> static class VerifyingCollector implements SpanCollector {
>> >>     List<BytesRef> payloads = new ArrayList<>();
>> >>     @Override
>> >>     public void collectLeaf(PostingsEnum postings, int position, Term
>> term) throws IOException {
>> >>      ....
>> >>      }
>> >> }
>> >>
>> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>> tests collectLeaf for query
>> >>
>> >> //initialise term
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>> before term1=new org.apache.lucene.index.Term('field','withPayload')");
>> >> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
>> "withPayload");
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>> term1="+term1);
>> >>
>> >> //assume position is 5
>> >>     int position=5;
>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>> position="+position);
>> >>
>> >>     BytesRef pay = new BytesRef("pos: " + position);
>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>> pay="+pay);
>> >>
>> >> //build spanQuery with term parameter
>> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>> SpanTermQuery(term1);
>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>> spanQuery1="+spanQuery1);
>> >>
>> >> //add BytesRef to payloadToMatch list
>> >>     java.util.List<org.apache.lucene.util.BytesRef>
>> payloadToMatch=new java.util.ArrayList<org.apache
>> .lucene.util.BytesRef>();
>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>> payloadToMatch="+payloadToMatch);
>> >>     payloadToMatch.add(pay);
>> >>
>> >> //build SpanPayloadCheckQuery
>> >> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>> >> (org.apache.lucene.search.spans.SpanQuery)query,
>> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>> query="+query);
>> >>
>> >> //build lucene Directory (TODO: we should use an existing directory
>> with REAL test-data)
>> >> org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.
>> randomizedtesting.RandomizedContext.current().getRandom());
>> >>
>> >> //build SegmentReader from Directory
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>> ram="+ram);
>> >> SegmentReader reader = getOnlySegmentReader(org.apach
>> e.lucene.index.DirectoryReader.open(ram));
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>> reader="+reader);
>> >>
>> >> //populate SlowCompositeReaderWrapper with SegmentReader
>> >>     org.apache.lucene.index.LeafReader sr =
>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>> sr="+sr);
>> >>
>> >> //add term to SegmentReader postings
>> >> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>> PostingsEnum.PAYLOADS);
>> >>
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> postings="+postings);
>> >>
>> >> //display the parameters for collectLeaf method for query:
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> position="+position);
>> >>
>> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>> >>     try
>> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>> postings, int position,       //org.apache.lucene.index.Term term)
>> throws java.io.IOException {
>> >> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1);
>> >> }
>> >> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>> IOException ="+ioe.getMessage()); }
>> >>
>> >> collectLeaf is the only method that compares
>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>> >> to determine "match"
>> >>
>> >> unless of course match between individual payload and payloadToMatch
>> is tested elsewhere ?
>> >>
>> >> WDYT?
>> >> Martin
>> >> ______________________________________________
>> >>
>> >>
>> >>
>> >> From: Erik Hatcher <er...@gmail.com>
>> >> Sent: Saturday, April 29, 2017 7:58 PM
>> >> To: Lucene/Solr dev
>> >> Subject: Re: Release 6.6
>> >>
>> >> Martin -
>> >>
>> >> Interesting test but I couldn’t copy/paste it in to try it out as it
>> uses some logging and APIs that aren’t already in the project and classpath
>> of these lucene tests within that queries module (within IntelliJ, mind
>> you).
>> >>
>> >> I was able to resolve the misunderstanding (and .equals/.hashCode
>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>> me now.   Do your tests point out an issue?   Or confirming that it is
>> working properly at a lower level?
>> >>
>> >> Erik
>> >>
>> >>
>> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>> wrote:
>> >>>
>> >>> Martin Gainty has shared a OneDrive file with you. To view it, click
>> the link below.
>> >>>
>> >>> TestPayloadCheckQuery.java
>> >>> attached
>> >>>
>> >>> I coded this last nite so it is "quick and dirty"
>> >>>
>> >>> in any case let me know if  testSpanPayloadCheck() method
>> modification properly addresses your situation
>> >>>
>> >>> Thanks!
>> >>> Martin
>> >>> ______________________________________________
>> >>>
>> >>>
>> >>>
>> >>> From: Erik Hatcher <er...@gmail.com>
>> >>> Sent: Saturday, April 29, 2017 8:58 AM
>> >>> To: dev@lucene.apache.org
>> >>> Subject: Re: Release 6.6
>> >>>
>> >>> Martin - there is a test class specifically for this query.   See the
>> recent commits I've made to test it further fixing .equals/.hashCode and
>> rewrite.
>> >>>
>> >>> Can you send your full test code?
>> >>>
>> >>>    Erik
>> >>>
>> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>> >>>
>> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
>> was about to reply just run that TestCase
>> >>>> (until i discovered there wasnt any!)
>> >>>>
>> >>>> i'll start the bidding at 1 dinar for TestCase
>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>> >>>>   @org.junit.Test
>> >>>>   public void testSpanPayloadCheck() throws Exception
>> >>>>
>> >>>>     //now lets test the collectLeaf for query
>> >>>>     //of course calling Base Class SpanPayloadCheckQuery to
>> construct query
>> >>>>
>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> postings="+postings);
>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> position="+position);
>> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>> >>>>
>> >>>>     try
>> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>> postings, int position,              //org.apache.lucene.index.Term term)
>> throws java.io.IOException {
>> >>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1);
>> >>>> }
>> >>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>> IOException ="+ioe.getMessage()); }
>> >>>>
>> >>>> unless of course anyone has a better idea to test collectLeaf ?
>> >>>> Martin
>> >>>> ______________________________________________
>> >>>>
>> >>>>
>> >>>>
>> >>>> From: Erik Hatcher <er...@gmail.com>
>> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
>> >>>> To: dev@lucene.apache.org
>> >>>> Subject: Re: Release 6.6
>> >>>>
>> >>>> Probably no bribe needed, but an updated patch would be a good start
>> (or will the 2.5 year old patch still apply and be acceptable as-is?)
>> >>>>
>> >>>> Erik
>> >>>>
>> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <
>> wunder@wunderwood.org> wrote:
>> >>>>>
>> >>>>> Who do I have to bribe to get SOLR-629 included?
>> >>>>>
>> >>>>> https://issues.apache.org/jira/browse/SOLR-629
>> >>>>>
>> >>>>> wunder
>> >>>>> Walter Underwood
>> >>>>> wunder@wunderwood.org
>> >>>>> http://observer.wunderwood.org/  (my blog)
>> >>>>>
>> >>>>>
>> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd
>> like to propose a 6.6 release (perhaps the last 6x non-bug-fix release
>> before 7.0 release).
>> >>>>>>
>> >>>>>> I can volunteer to release this, and I can cut the release branch
>> around 4th May, in order to let some time for devs to finish current issues.
>> >>>>>>
>> >>>>>> What do you think?
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> Ishan
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Sure Steve! Thanks!

On Sun, May 14, 2017 at 2:34 PM, Steve Rowe <sa...@gmail.com> wrote:

> Ishan,
>
> Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 for 6.6?
>
> --
> Steve
> www.lucidworks.com
>
> > On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com>
> wrote:
> >
> > Ok thanks Ishan.
> >
> > Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <ic...@gmail.com>
> a écrit :
> > Sure, Jim. Please go ahead!
> >
> > On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <ji...@gmail.com>
> wrote:
> > Hi,
> > Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824
> included for 6.6. Can I merge the fix this week end Ishan ?
> >
> > 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com>:
> > Done, Adrien. Thanks!
> >
> > On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com> wrote:
> > Ishan, wdyt about running addVersion on the branch_6x/master as well? I
> think it would help realize that the 6.6 branch has been cut when looking
> at the CHANGES.txt file and not forget about backporting?
> >
> > Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> a écrit :
> > I've cut the branch for 6.6. (branch_6_6). Please feel free to add
> bugfixes to the branch, if needed.
> > Planning to build the first RC on 15 May. Please let me know if there
> are any objections.
> >
> > Thanks,
> > Ishan
> >
> > On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> > Planning to cut the release branch in another 10-12 hours.
> >
> > On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
> wrote:
> > i was wondering if there was a specific test for SpanPayloadCheckQuery
> method
> >
> > matches = payloadToMatch.get(upto).bytesEquals(payload);
> >
> >
> >
> > the only implementation i could locate was in collectLeaf of
> SpanPayloadCheckQuery
> >
> >
> > I will submit JIRA with Patch
> >
> >
> > as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
> fragments (what we called phenomes) than current SEO implementations
> >
> >
> > Can you suggest a book to read to better understand Lucenes pattern
> dissection and match algorithms?
> >
> >
> > Many Thanks for helpful guidance
> > Martin
> > ______________________________________________
> >
> >
> >
> > From: Erik Hatcher <er...@gmail.com>
> > Sent: Sunday, April 30, 2017 2:06 PM
> >
> > To: dev@lucene.apache.org
> > Subject: Re: Release 6.6
> >
> > Martin -
> >
> > I have to admit to still being unsure what the gist is here - is there a
> bug?   Apologies for not catching what you’re saying/showing here.  Again,
> as far as I can tell SpanPayloadCheckQuery is working as expected now.
> >
> > I’m going to focus purely on SOLR-1485 this week to get it committed for
> 6.6.  If there is an issue to address with your work would you please open
> a JIRA and include your patch there?
> >
> > Thanks,
> > Erik
> >
> >
> >> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com> wrote:
> >>
> >> Mornin' Erik
> >>
> >> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans
> ..but its never called:
> >>
> >> static class VerifyingCollector implements SpanCollector {
> >>     List<BytesRef> payloads = new ArrayList<>();
> >>     @Override
> >>     public void collectLeaf(PostingsEnum postings, int position, Term
> term) throws IOException {
> >>      ....
> >>      }
> >> }
> >>
> >> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery
> tests collectLeaf for query
> >>
> >> //initialise term
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before
> term1=new org.apache.lucene.index.Term('field','withPayload')");
> >> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
> "withPayload");
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
> term1="+term1);
> >>
> >> //assume position is 5
> >>     int position=5;
> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
> position="+position);
> >>
> >>     BytesRef pay = new BytesRef("pos: " + position);
> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
> pay="+pay);
> >>
> >> //build spanQuery with term parameter
> >>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
> SpanTermQuery(term1);
> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
> spanQuery1="+spanQuery1);
> >>
> >> //add BytesRef to payloadToMatch list
> >>     java.util.List<org.apache.lucene.util.BytesRef> payloadToMatch=new
> java.util.ArrayList<org.apache.lucene.util.BytesRef>();
> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
> payloadToMatch="+payloadToMatch);
> >>     payloadToMatch.add(pay);
> >>
> >> //build SpanPayloadCheckQuery
> >> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
> >> (org.apache.lucene.search.spans.SpanQuery)query,
> >> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
> query="+query);
> >>
> >> //build lucene Directory (TODO: we should use an existing directory
> with REAL test-data)
> >> org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.
> randomizedtesting.RandomizedContext.current().getRandom());
> >>
> >> //build SegmentReader from Directory
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
> ram="+ram);
> >> SegmentReader reader = getOnlySegmentReader(org.apache.lucene.index.
> DirectoryReader.open(ram));
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
> reader="+reader);
> >>
> >> //populate SlowCompositeReaderWrapper with SegmentReader
> >>     org.apache.lucene.index.LeafReader sr = org.apache.lucene.index.
> SlowCompositeReaderWrapper.wrap(reader);
> >>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
> sr="+sr);
> >>
> >> //add term to SegmentReader postings
> >> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
> PostingsEnum.PAYLOADS);
> >>
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where postings="+postings);
> >>
> >> //display the parameters for collectLeaf method for query:
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where position="+position);
> >>
> >> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where term1="+term1);
> >>     try
> >>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
> postings, int position,       //org.apache.lucene.index.Term term) throws
> java.io.IOException {
> >> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
> lucene.index.Term)term1);
> >> }
> >> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> LINE 106 throws IOException ="+ioe.getMessage()); }
> >>
> >> collectLeaf is the only method that compares matches=payloadToMatch.get(
> upto).bytesEquals(payload)
> >> to determine "match"
> >>
> >> unless of course match between individual payload and payloadToMatch is
> tested elsewhere ?
> >>
> >> WDYT?
> >> Martin
> >> ______________________________________________
> >>
> >>
> >>
> >> From: Erik Hatcher <er...@gmail.com>
> >> Sent: Saturday, April 29, 2017 7:58 PM
> >> To: Lucene/Solr dev
> >> Subject: Re: Release 6.6
> >>
> >> Martin -
> >>
> >> Interesting test but I couldn’t copy/paste it in to try it out as it
> uses some logging and APIs that aren’t already in the project and classpath
> of these lucene tests within that queries module (within IntelliJ, mind
> you).
> >>
> >> I was able to resolve the misunderstanding (and .equals/.hashCode bugs)
> so everything is working as expected with SpanPayloadCheckQuery for me
> now.   Do your tests point out an issue?   Or confirming that it is working
> properly at a lower level?
> >>
> >> Erik
> >>
> >>
> >>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
> wrote:
> >>>
> >>> Martin Gainty has shared a OneDrive file with you. To view it, click
> the link below.
> >>>
> >>> TestPayloadCheckQuery.java
> >>> attached
> >>>
> >>> I coded this last nite so it is "quick and dirty"
> >>>
> >>> in any case let me know if  testSpanPayloadCheck() method modification
> properly addresses your situation
> >>>
> >>> Thanks!
> >>> Martin
> >>> ______________________________________________
> >>>
> >>>
> >>>
> >>> From: Erik Hatcher <er...@gmail.com>
> >>> Sent: Saturday, April 29, 2017 8:58 AM
> >>> To: dev@lucene.apache.org
> >>> Subject: Re: Release 6.6
> >>>
> >>> Martin - there is a test class specifically for this query.   See the
> recent commits I've made to test it further fixing .equals/.hashCode and
> rewrite.
> >>>
> >>> Can you send your full test code?
> >>>
> >>>    Erik
> >>>
> >>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
> >>>
> >>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
> was about to reply just run that TestCase
> >>>> (until i discovered there wasnt any!)
> >>>>
> >>>> i'll start the bidding at 1 dinar for TestCase
> org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
> >>>>   @org.junit.Test
> >>>>   public void testSpanPayloadCheck() throws Exception
> >>>>
> >>>>     //now lets test the collectLeaf for query
> >>>>     //of course calling Base Class SpanPayloadCheckQuery to construct
> query
> >>>>
> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
> before query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where postings="+postings);
> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
> before query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where position="+position);
> >>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
> before query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where term1="+term1);
> >>>>
> >>>>     try
> >>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
> postings, int position,              //org.apache.lucene.index.Term term)
> throws java.io.IOException {
> >>>> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
> lucene.index.Term)term1);
> >>>> }
> >>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> LINE 106 throws IOException ="+ioe.getMessage()); }
> >>>>
> >>>> unless of course anyone has a better idea to test collectLeaf ?
> >>>> Martin
> >>>> ______________________________________________
> >>>>
> >>>>
> >>>>
> >>>> From: Erik Hatcher <er...@gmail.com>
> >>>> Sent: Tuesday, April 25, 2017 7:57 PM
> >>>> To: dev@lucene.apache.org
> >>>> Subject: Re: Release 6.6
> >>>>
> >>>> Probably no bribe needed, but an updated patch would be a good start
> (or will the 2.5 year old patch still apply and be acceptable as-is?)
> >>>>
> >>>> Erik
> >>>>
> >>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
> wrote:
> >>>>>
> >>>>> Who do I have to bribe to get SOLR-629 included?
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/SOLR-629
> >>>>>
> >>>>> wunder
> >>>>> Walter Underwood
> >>>>> wunder@wunderwood.org
> >>>>> http://observer.wunderwood.org/  (my blog)
> >>>>>
> >>>>>
> >>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like
> to propose a 6.6 release (perhaps the last 6x non-bug-fix release before
> 7.0 release).
> >>>>>>
> >>>>>> I can volunteer to release this, and I can cut the release branch
> around 4th May, in order to let some time for devs to finish current issues.
> >>>>>>
> >>>>>> What do you think?
> >>>>>>
> >>>>>> Regards,
> >>>>>> Ishan
> >
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Release 6.6

Posted by Steve Rowe <sa...@gmail.com>.
Ishan,

Okay to include https://issues.apache.org/jira/browse/LUCENE-7821 for 6.6?

--
Steve
www.lucidworks.com

> On May 12, 2017, at 12:51 PM, jim ferenczi <ji...@gmail.com> wrote:
> 
> Ok thanks Ishan.
> 
> Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <ic...@gmail.com> a écrit :
> Sure, Jim. Please go ahead!
> 
> On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <ji...@gmail.com> wrote:
> Hi,
> Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824 included for 6.6. Can I merge the fix this week end Ishan ?
> 
> 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <ic...@gmail.com>:
> Done, Adrien. Thanks!
> 
> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com> wrote:
> Ishan, wdyt about running addVersion on the branch_6x/master as well? I think it would help realize that the 6.6 branch has been cut when looking at the CHANGES.txt file and not forget about backporting?
> 
> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <ic...@gmail.com> a écrit :
> I've cut the branch for 6.6. (branch_6_6). Please feel free to add bugfixes to the branch, if needed.
> Planning to build the first RC on 15 May. Please let me know if there are any objections.
> 
> Thanks,
> Ishan
> 
> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
> Planning to cut the release branch in another 10-12 hours.
> 
> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com> wrote:
> i was wondering if there was a specific test for SpanPayloadCheckQuery method
> 
> matches = payloadToMatch.get(upto).bytesEquals(payload);
> 
> 
> 
> the only implementation i could locate was in collectLeaf of SpanPayloadCheckQuery
> 
> 
> I will submit JIRA with Patch
> 
> 
> as a CS *dinosaur* I am more familiar with LISP for dissecting sentence fragments (what we called phenomes) than current SEO implementations
> 
> 
> Can you suggest a book to read to better understand Lucenes pattern dissection and match algorithms?
> 
> 
> Many Thanks for helpful guidance
> Martin  
> ______________________________________________ 
> 
> 
> 
> From: Erik Hatcher <er...@gmail.com>
> Sent: Sunday, April 30, 2017 2:06 PM
> 
> To: dev@lucene.apache.org
> Subject: Re: Release 6.6
>  
> Martin -
> 
> I have to admit to still being unsure what the gist is here - is there a bug?   Apologies for not catching what you’re saying/showing here.  Again, as far as I can tell SpanPayloadCheckQuery is working as expected now.  
> 
> I’m going to focus purely on SOLR-1485 this week to get it committed for 6.6.  If there is an issue to address with your work would you please open a JIRA and include your patch there?
> 
> Thanks,
> Erik
> 
> 
>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com> wrote:
>> 
>> Mornin' Erik
>> 
>> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:
>> 
>> static class VerifyingCollector implements SpanCollector {
>>     List<BytesRef> payloads = new ArrayList<>();
>>     @Override
>>     public void collectLeaf(PostingsEnum postings, int position, Term term) throws IOException {
>>      ....
>>      }
>> }
>> 
>> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf for query
>> 
>> //initialise term
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before term1=new org.apache.lucene.index.Term('field','withPayload')");
>> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field", "withPayload");
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233 term1="+term1);
>> 
>> //assume position is 5
>>     int position=5;
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235 position="+position);
>> 
>>     BytesRef pay = new BytesRef("pos: " + position);
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237 pay="+pay);
>> 
>> //build spanQuery with term parameter
>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new SpanTermQuery(term1);
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239 spanQuery1="+spanQuery1);
>> 
>> //add BytesRef to payloadToMatch list
>>     java.util.List<org.apache.lucene.util.BytesRef> payloadToMatch=new java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241 payloadToMatch="+payloadToMatch);
>>     payloadToMatch.add(pay);
>> 
>> //build SpanPayloadCheckQuery
>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>> (org.apache.lucene.search.spans.SpanQuery)query,
>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249 query="+query);
>> 
>> //build lucene Directory (TODO: we should use an existing directory with REAL test-data)
>> org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>> 
>> //build SegmentReader from Directory
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251 ram="+ram);
>> SegmentReader reader = getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253 reader="+reader);
>> 
>> //populate SlowCompositeReaderWrapper with SegmentReader
>>     org.apache.lucene.index.LeafReader sr = org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255 sr="+sr);
>> 
>> //add term to SegmentReader postings
>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1, PostingsEnum.PAYLOADS);
>> 
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
>> 
>> //display the parameters for collectLeaf method for query:
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
>> 
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>     try
>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,       //org.apache.lucene.index.Term term) throws java.io.IOException {
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1);
>> }
>> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException ="+ioe.getMessage()); }
>> 
>> collectLeaf is the only method that compares matches=payloadToMatch.get(upto).bytesEquals(payload)
>> to determine "match"
>> 
>> unless of course match between individual payload and payloadToMatch is tested elsewhere ?
>> 
>> WDYT?
>> Martin 
>> ______________________________________________ 
>> 
>> 
>> 
>> From: Erik Hatcher <er...@gmail.com>
>> Sent: Saturday, April 29, 2017 7:58 PM
>> To: Lucene/Solr dev
>> Subject: Re: Release 6.6
>>  
>> Martin -
>> 
>> Interesting test but I couldn’t copy/paste it in to try it out as it uses some logging and APIs that aren’t already in the project and classpath of these lucene tests within that queries module (within IntelliJ, mind you).
>> 
>> I was able to resolve the misunderstanding (and .equals/.hashCode bugs) so everything is working as expected with SpanPayloadCheckQuery for me now.   Do your tests point out an issue?   Or confirming that it is working properly at a lower level?
>> 
>> Erik
>> 
>> 
>>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com> wrote:
>>> 
>>> Martin Gainty has shared a OneDrive file with you. To view it, click the link below.
>>>  
>>> TestPayloadCheckQuery.java
>>> attached
>>> 
>>> I coded this last nite so it is "quick and dirty"
>>> 
>>> in any case let me know if  testSpanPayloadCheck() method modification properly addresses your situation
>>> 
>>> Thanks!
>>> Martin 
>>> ______________________________________________ 
>>> 
>>> 
>>> 
>>> From: Erik Hatcher <er...@gmail.com>
>>> Sent: Saturday, April 29, 2017 8:58 AM
>>> To: dev@lucene.apache.org
>>> Subject: Re: Release 6.6
>>>  
>>> Martin - there is a test class specifically for this query.   See the recent commits I've made to test it further fixing .equals/.hashCode and rewrite. 
>>> 
>>> Can you send your full test code?
>>> 
>>>    Erik
>>> 
>>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>>> 
>>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about to reply just run that TestCase
>>>> (until i discovered there wasnt any!)
>>>> 
>>>> i'll start the bidding at 1 dinar for TestCase org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>   @org.junit.Test
>>>>   public void testSpanPayloadCheck() throws Exception
>>>> 
>>>>     //now lets test the collectLeaf for query
>>>>     //of course calling Base Class SpanPayloadCheckQuery to construct query
>>>> 
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>> 
>>>>     try
>>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,              //org.apache.lucene.index.Term term) throws java.io.IOException {
>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1);
>>>> }
>>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException ="+ioe.getMessage()); }
>>>> 
>>>> unless of course anyone has a better idea to test collectLeaf ?
>>>> Martin 
>>>> ______________________________________________ 
>>>> 
>>>> 
>>>> 
>>>> From: Erik Hatcher <er...@gmail.com>
>>>> Sent: Tuesday, April 25, 2017 7:57 PM
>>>> To: dev@lucene.apache.org
>>>> Subject: Re: Release 6.6
>>>>  
>>>> Probably no bribe needed, but an updated patch would be a good start (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>> 
>>>> Erik
>>>> 
>>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org> wrote:
>>>>> 
>>>>> Who do I have to bribe to get SOLR-629 included?
>>>>> 
>>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>> 
>>>>> wunder
>>>>> Walter Underwood
>>>>> wunder@wunderwood.org
>>>>> http://observer.wunderwood.org/  (my blog)
>>>>> 
>>>>> 
>>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like to propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 release).
>>>>>> 
>>>>>> I can volunteer to release this, and I can cut the release branch around 4th May, in order to let some time for devs to finish current issues.
>>>>>> 
>>>>>> What do you think?
>>>>>> 
>>>>>> Regards,
>>>>>> Ishan
> 
> 
> 
> 
> 
> 
> 


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


Re: Release 6.6

Posted by jim ferenczi <ji...@gmail.com>.
Ok thanks Ishan.

Le 12 mai 2017 18:44, "Ishan Chattopadhyaya" <ic...@gmail.com> a
écrit :

Sure, Jim. Please go ahead!

On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <ji...@gmail.com>
wrote:

> Hi,
> Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824
> included for 6.6. Can I merge the fix this week end Ishan ?
>
> 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <ichattopadhyaya@gmail.com
> >:
>
>> Done, Adrien. Thanks!
>>
>> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com> wrote:
>>
>>> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
>>> think it would help realize that the 6.6 branch has been cut when looking
>>> at the CHANGES.txt file and not forget about backporting?
>>>
>>> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> a écrit :
>>>
>>>> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>>> bugfixes to the branch, if needed.
>>>> Planning to build the first RC on 15 May. Please let me know if there
>>>> are any objections.
>>>>
>>>> Thanks,
>>>> Ishan
>>>>
>>>> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>>
>>>>> Planning to cut the release branch in another 10-12 hours.
>>>>>
>>>>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>>
>>>>>> i was wondering if there was a specific test for
>>>>>> SpanPayloadCheckQuery method
>>>>>>
>>>>>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>
>>>>>>
>>>>>> the only implementation i could locate was in collectLeaf of
>>>>>> SpanPayloadCheckQuery
>>>>>>
>>>>>>
>>>>>> I will submit JIRA with Patch
>>>>>>
>>>>>>
>>>>>> as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>> implementations
>>>>>>
>>>>>>
>>>>>> Can you suggest a book to read to better understand Lucenes pattern
>>>>>> dissection and match algorithms?
>>>>>>
>>>>>>
>>>>>> Many Thanks for helpful guidance
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>>>>>
>>>>>> *To:* dev@lucene.apache.org
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Martin -
>>>>>>
>>>>>> I have to admit to still being unsure what the gist is here - is
>>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>> now.
>>>>>>
>>>>>> I’m going to focus purely on SOLR-1485 this week to get it committed
>>>>>> for 6.6.  If there is an issue to address with your work would you please
>>>>>> open a JIRA and include your patch there?
>>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Mornin' Erik
>>>>>>
>>>>>> there is a collectLeaf  override in org.apache.lucene
>>>>>> .queries.payloads.TestPayloadSpans ..but its never called:
>>>>>>
>>>>>> static class VerifyingCollector implements SpanCollector {
>>>>>>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>     @Override
>>>>>>     public void collectLeaf(PostingsEnum postings, int position, Term
>>>>>> term) throws IOException {
>>>>>>      ....
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> the modification in org.apache.lucene.queries.payl
>>>>>> oads.TestPayloadCheckQuery tests collectLeaf for query
>>>>>>
>>>>>> //initialise term
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>> before term1=new org.apache.lucene.index.Term('
>>>>>> field','withPayload')");
>>>>>> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
>>>>>> "withPayload");
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>> term1="+term1);
>>>>>>
>>>>>> //assume position is 5
>>>>>>     int position=5;
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>>>>> position="+position);
>>>>>>
>>>>>>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>>>>> pay="+pay);
>>>>>>
>>>>>> //build spanQuery with term parameter
>>>>>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>> SpanTermQuery(term1);
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>>>>> spanQuery1="+spanQuery1);
>>>>>>
>>>>>> //add BytesRef to payloadToMatch list
>>>>>>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>> payloadToMatch=new java.util.ArrayList<org.apache
>>>>>> .lucene.util.BytesRef>();
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>>>>> payloadToMatch="+payloadToMatch);
>>>>>>     payloadToMatch.add(pay);
>>>>>>
>>>>>> //build SpanPayloadCheckQuery
>>>>>>
>>>>>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>>> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>> query="+query);
>>>>>>
>>>>>> //build lucene Directory (TODO: we should use an existing directory
>>>>>> with REAL test-data)
>>>>>> org.apache.lucene.store.Directory ram =
>>>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedCo
>>>>>> ntext.current().getRandom());
>>>>>>
>>>>>> //build SegmentReader from Directory
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>> ram="+ram);
>>>>>> SegmentReader reader = getOnlySegmentReader(org.apach
>>>>>> e.lucene.index.DirectoryReader.open(ram));
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>> reader="+reader);
>>>>>>
>>>>>> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>     org.apache.lucene.index.LeafReader sr =
>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>>>>>> sr="+sr);
>>>>>>
>>>>>> //add term to SegmentReader postings
>>>>>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>>>>> PostingsEnum.PAYLOADS);
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> postings="+postings);
>>>>>>
>>>>>> //display the parameters for collectLeaf method for query:
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> position="+position);
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> term1="+term1);
>>>>>>     try
>>>>>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>> postings, int position,       //org.apache.lucene.index.Term term) throws
>>>>>> java.io.IOException {
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>> }
>>>>>> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>
>>>>>> collectLeaf is the only method that compares
>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>
>>>>>> to determine "match"
>>>>>>
>>>>>> unless of course match between individual payload and payloadToMatch
>>>>>> is tested elsewhere ?
>>>>>>
>>>>>> WDYT?
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Saturday, April 29, 2017 7:58 PM
>>>>>> *To:* Lucene/Solr dev
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Martin -
>>>>>>
>>>>>> Interesting test but I couldn’t copy/paste it in to try it out as it
>>>>>> uses some logging and APIs that aren’t already in the project and classpath
>>>>>> of these lucene tests within that queries module (within IntelliJ, mind
>>>>>> you).
>>>>>>
>>>>>> I was able to resolve the misunderstanding (and .equals/.hashCode
>>>>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>>>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>>>>> working properly at a lower level?
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Martin Gainty has shared a OneDrive file with you. To view it, click
>>>>>> the link below.
>>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>>> TestPayloadCheckQuery.java
>>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>>> attached
>>>>>>
>>>>>> I coded this last nite so it is "quick and dirty"
>>>>>>
>>>>>> in any case let me know if  testSpanPayloadCheck()
>>>>>> method modification properly addresses your situation
>>>>>>
>>>>>> Thanks!
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Saturday, April 29, 2017 8:58 AM
>>>>>> *To:* dev@lucene.apache.org
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Martin - there is a test class specifically for this query.   See the
>>>>>> recent commits I've made to test it further fixing .equals/.hashCode and
>>>>>> rewrite.
>>>>>>
>>>>>> Can you send your full test code?
>>>>>>
>>>>>>    Erik
>>>>>>
>>>>>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>>>>>>
>>>>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
>>>>>> was about to reply just run that TestCase
>>>>>> (until i discovered there wasnt any!)
>>>>>>
>>>>>> i'll start the bidding at 1 dinar for TestCase org.apache.lucene
>>>>>> .queries.payloads.TestPayloadCheckQuery mod:
>>>>>>   @org.junit.Test
>>>>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>
>>>>>>
>>>>>>     //now lets test the collectLeaf for query
>>>>>>     //of course calling Base Class SpanPayloadCheckQuery to construct
>>>>>> query
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> postings="+postings);
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> position="+position);
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> term1="+term1);
>>>>>>
>>>>>>     try
>>>>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>> postings, int position,              //org.apache.lucene.index.Term
>>>>>> term) throws java.io.IOException {
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>> }
>>>>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>
>>>>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Tuesday, April 25, 2017 7:57 PM
>>>>>> *To:* dev@lucene.apache.org
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Probably no bribe needed, but an updated patch would be a good start
>>>>>> (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
>>>>>> wrote:
>>>>>>
>>>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>
>>>>>> wunder
>>>>>> Walter Underwood
>>>>>> wunder@wunderwood.org
>>>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>
>>>>>>
>>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like
>>>>>> to propose a 6.6 release (perhaps the last 6x non-bug-fix release before
>>>>>> 7.0 release).
>>>>>>
>>>>>> I can volunteer to release this, and I can cut the release branch
>>>>>> around 4th May, in order to let some time for devs to finish current issues.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Regards,
>>>>>> Ishan
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Sure, Jim. Please go ahead!

On Fri, May 12, 2017 at 10:01 PM, jim ferenczi <ji...@gmail.com>
wrote:

> Hi,
> Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824
> included for 6.6. Can I merge the fix this week end Ishan ?
>
> 2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <ichattopadhyaya@gmail.com
> >:
>
>> Done, Adrien. Thanks!
>>
>> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com> wrote:
>>
>>> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
>>> think it would help realize that the 6.6 branch has been cut when looking
>>> at the CHANGES.txt file and not forget about backporting?
>>>
>>> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> a écrit :
>>>
>>>> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>>> bugfixes to the branch, if needed.
>>>> Planning to build the first RC on 15 May. Please let me know if there
>>>> are any objections.
>>>>
>>>> Thanks,
>>>> Ishan
>>>>
>>>> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>>
>>>>> Planning to cut the release branch in another 10-12 hours.
>>>>>
>>>>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>>
>>>>>> i was wondering if there was a specific test for
>>>>>> SpanPayloadCheckQuery method
>>>>>>
>>>>>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>>
>>>>>>
>>>>>> the only implementation i could locate was in collectLeaf of
>>>>>> SpanPayloadCheckQuery
>>>>>>
>>>>>>
>>>>>> I will submit JIRA with Patch
>>>>>>
>>>>>>
>>>>>> as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>>> implementations
>>>>>>
>>>>>>
>>>>>> Can you suggest a book to read to better understand Lucenes pattern
>>>>>> dissection and match algorithms?
>>>>>>
>>>>>>
>>>>>> Many Thanks for helpful guidance
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>>>>>
>>>>>> *To:* dev@lucene.apache.org
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Martin -
>>>>>>
>>>>>> I have to admit to still being unsure what the gist is here - is
>>>>>> there a bug?   Apologies for not catching what you’re saying/showing here.
>>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>>> now.
>>>>>>
>>>>>> I’m going to focus purely on SOLR-1485 this week to get it committed
>>>>>> for 6.6.  If there is an issue to address with your work would you please
>>>>>> open a JIRA and include your patch there?
>>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Mornin' Erik
>>>>>>
>>>>>> there is a collectLeaf  override in org.apache.lucene
>>>>>> .queries.payloads.TestPayloadSpans ..but its never called:
>>>>>>
>>>>>> static class VerifyingCollector implements SpanCollector {
>>>>>>     List<BytesRef> payloads = new ArrayList<>();
>>>>>>     @Override
>>>>>>     public void collectLeaf(PostingsEnum postings, int position, Term
>>>>>> term) throws IOException {
>>>>>>      ....
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> the modification in org.apache.lucene.queries.payl
>>>>>> oads.TestPayloadCheckQuery tests collectLeaf for query
>>>>>>
>>>>>> //initialise term
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>>> before term1=new org.apache.lucene.index.Term('
>>>>>> field','withPayload')");
>>>>>> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
>>>>>> "withPayload");
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>>> term1="+term1);
>>>>>>
>>>>>> //assume position is 5
>>>>>>     int position=5;
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>>>>> position="+position);
>>>>>>
>>>>>>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>>>>> pay="+pay);
>>>>>>
>>>>>> //build spanQuery with term parameter
>>>>>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>>> SpanTermQuery(term1);
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>>>>> spanQuery1="+spanQuery1);
>>>>>>
>>>>>> //add BytesRef to payloadToMatch list
>>>>>>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>>> payloadToMatch=new java.util.ArrayList<org.apache
>>>>>> .lucene.util.BytesRef>();
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>>>>> payloadToMatch="+payloadToMatch);
>>>>>>     payloadToMatch.add(pay);
>>>>>>
>>>>>> //build SpanPayloadCheckQuery
>>>>>>
>>>>>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>>> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>>> query="+query);
>>>>>>
>>>>>> //build lucene Directory (TODO: we should use an existing directory
>>>>>> with REAL test-data)
>>>>>> org.apache.lucene.store.Directory ram =
>>>>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedCo
>>>>>> ntext.current().getRandom());
>>>>>>
>>>>>> //build SegmentReader from Directory
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>>> ram="+ram);
>>>>>> SegmentReader reader = getOnlySegmentReader(org.apach
>>>>>> e.lucene.index.DirectoryReader.open(ram));
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>>> reader="+reader);
>>>>>>
>>>>>> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>>     org.apache.lucene.index.LeafReader sr =
>>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>>>>>> sr="+sr);
>>>>>>
>>>>>> //add term to SegmentReader postings
>>>>>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>>>>> PostingsEnum.PAYLOADS);
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> postings="+postings);
>>>>>>
>>>>>> //display the parameters for collectLeaf method for query:
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> position="+position);
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> term1="+term1);
>>>>>>     try
>>>>>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>> postings, int position,       //org.apache.lucene.index.Term term) throws
>>>>>> java.io.IOException {
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>> }
>>>>>> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>
>>>>>> collectLeaf is the only method that compares
>>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>>
>>>>>> to determine "match"
>>>>>>
>>>>>> unless of course match between individual payload and payloadToMatch
>>>>>> is tested elsewhere ?
>>>>>>
>>>>>> WDYT?
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Saturday, April 29, 2017 7:58 PM
>>>>>> *To:* Lucene/Solr dev
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Martin -
>>>>>>
>>>>>> Interesting test but I couldn’t copy/paste it in to try it out as it
>>>>>> uses some logging and APIs that aren’t already in the project and classpath
>>>>>> of these lucene tests within that queries module (within IntelliJ, mind
>>>>>> you).
>>>>>>
>>>>>> I was able to resolve the misunderstanding (and .equals/.hashCode
>>>>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>>>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>>>>> working properly at a lower level?
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Martin Gainty has shared a OneDrive file with you. To view it, click
>>>>>> the link below.
>>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>>> TestPayloadCheckQuery.java
>>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>>> attached
>>>>>>
>>>>>> I coded this last nite so it is "quick and dirty"
>>>>>>
>>>>>> in any case let me know if  testSpanPayloadCheck()
>>>>>> method modification properly addresses your situation
>>>>>>
>>>>>> Thanks!
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Saturday, April 29, 2017 8:58 AM
>>>>>> *To:* dev@lucene.apache.org
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Martin - there is a test class specifically for this query.   See the
>>>>>> recent commits I've made to test it further fixing .equals/.hashCode and
>>>>>> rewrite.
>>>>>>
>>>>>> Can you send your full test code?
>>>>>>
>>>>>>    Erik
>>>>>>
>>>>>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>>>>>>
>>>>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
>>>>>> was about to reply just run that TestCase
>>>>>> (until i discovered there wasnt any!)
>>>>>>
>>>>>> i'll start the bidding at 1 dinar for TestCase org.apache.lucene
>>>>>> .queries.payloads.TestPayloadCheckQuery mod:
>>>>>>   @org.junit.Test
>>>>>>   public void testSpanPayloadCheck() throws Exception
>>>>>>
>>>>>>
>>>>>>     //now lets test the collectLeaf for query
>>>>>>     //of course calling Base Class SpanPayloadCheckQuery to construct
>>>>>> query
>>>>>>
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> postings="+postings);
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> position="+position);
>>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>>> term1="+term1);
>>>>>>
>>>>>>     try
>>>>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>>> postings, int position,              //org.apache.lucene.index.Term
>>>>>> term) throws java.io.IOException {
>>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>>> }
>>>>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>>> IOException ="+ioe.getMessage()); }
>>>>>>
>>>>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>>> Martin
>>>>>> ______________________________________________
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>>> *Sent:* Tuesday, April 25, 2017 7:57 PM
>>>>>> *To:* dev@lucene.apache.org
>>>>>> *Subject:* Re: Release 6.6
>>>>>>
>>>>>> Probably no bribe needed, but an updated patch would be a good start
>>>>>> (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
>>>>>> wrote:
>>>>>>
>>>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>>
>>>>>> wunder
>>>>>> Walter Underwood
>>>>>> wunder@wunderwood.org
>>>>>> http://observer.wunderwood.org/  (my blog)
>>>>>>
>>>>>>
>>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like
>>>>>> to propose a 6.6 release (perhaps the last 6x non-bug-fix release before
>>>>>> 7.0 release).
>>>>>>
>>>>>> I can volunteer to release this, and I can cut the release branch
>>>>>> around 4th May, in order to let some time for devs to finish current issues.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Regards,
>>>>>> Ishan
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>

Re: Release 6.6

Posted by jim ferenczi <ji...@gmail.com>.
Hi,
Would be great to have https://issues.apache.org/jira/browse/LUCENE-7824
included for 6.6. Can I merge the fix this week end Ishan ?

2017-05-11 16:45 GMT+02:00 Ishan Chattopadhyaya <ic...@gmail.com>:

> Done, Adrien. Thanks!
>
> On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com> wrote:
>
>> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
>> think it would help realize that the 6.6 branch has been cut when looking
>> at the CHANGES.txt file and not forget about backporting?
>>
>> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> a écrit :
>>
>>> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>>> bugfixes to the branch, if needed.
>>> Planning to build the first RC on 15 May. Please let me know if there
>>> are any objections.
>>>
>>> Thanks,
>>> Ishan
>>>
>>> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>>
>>>> Planning to cut the release branch in another 10-12 hours.
>>>>
>>>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>>> wrote:
>>>>
>>>>> i was wondering if there was a specific test for SpanPayloadCheckQuery
>>>>> method
>>>>>
>>>>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>>
>>>>>
>>>>> the only implementation i could locate was in collectLeaf of
>>>>> SpanPayloadCheckQuery
>>>>>
>>>>>
>>>>> I will submit JIRA with Patch
>>>>>
>>>>>
>>>>> as a CS *dinosaur* I am more familiar with LISP for dissecting
>>>>> sentence fragments (what we called phenomes) than current SEO
>>>>> implementations
>>>>>
>>>>>
>>>>> Can you suggest a book to read to better understand Lucenes pattern
>>>>> dissection and match algorithms?
>>>>>
>>>>>
>>>>> Many Thanks for helpful guidance
>>>>> Martin
>>>>> ______________________________________________
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>>>>
>>>>> *To:* dev@lucene.apache.org
>>>>> *Subject:* Re: Release 6.6
>>>>>
>>>>> Martin -
>>>>>
>>>>> I have to admit to still being unsure what the gist is here - is there
>>>>> a bug?   Apologies for not catching what you’re saying/showing here.
>>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>>> now.
>>>>>
>>>>> I’m going to focus purely on SOLR-1485 this week to get it committed
>>>>> for 6.6.  If there is an issue to address with your work would you please
>>>>> open a JIRA and include your patch there?
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>>
>>>>>
>>>>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>>
>>>>> Mornin' Erik
>>>>>
>>>>> there is a collectLeaf  override in org.apache.lucene
>>>>> .queries.payloads.TestPayloadSpans ..but its never called:
>>>>>
>>>>> static class VerifyingCollector implements SpanCollector {
>>>>>     List<BytesRef> payloads = new ArrayList<>();
>>>>>     @Override
>>>>>     public void collectLeaf(PostingsEnum postings, int position, Term
>>>>> term) throws IOException {
>>>>>      ....
>>>>>      }
>>>>> }
>>>>>
>>>>>
>>>>> the modification in org.apache.lucene.queries.payl
>>>>> oads.TestPayloadCheckQuery tests collectLeaf for query
>>>>>
>>>>> //initialise term
>>>>>
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231
>>>>> before term1=new org.apache.lucene.index.Term('
>>>>> field','withPayload')");
>>>>> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
>>>>> "withPayload");
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>>> term1="+term1);
>>>>>
>>>>> //assume position is 5
>>>>>     int position=5;
>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>>>> position="+position);
>>>>>
>>>>>     BytesRef pay = new BytesRef("pos: " + position);
>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>>>> pay="+pay);
>>>>>
>>>>> //build spanQuery with term parameter
>>>>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>>> SpanTermQuery(term1);
>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>>>> spanQuery1="+spanQuery1);
>>>>>
>>>>> //add BytesRef to payloadToMatch list
>>>>>     java.util.List<org.apache.lucene.util.BytesRef>
>>>>> payloadToMatch=new java.util.ArrayList<org.apache
>>>>> .lucene.util.BytesRef>();
>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>>>> payloadToMatch="+payloadToMatch);
>>>>>     payloadToMatch.add(pay);
>>>>>
>>>>> //build SpanPayloadCheckQuery
>>>>>
>>>>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>>> (org.apache.lucene.search.spans.SpanQuery)query,
>>>>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>>> query="+query);
>>>>>
>>>>> //build lucene Directory (TODO: we should use an existing directory
>>>>> with REAL test-data)
>>>>> org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.
>>>>> randomizedtesting.RandomizedContext.current().getRandom());
>>>>>
>>>>> //build SegmentReader from Directory
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>>> ram="+ram);
>>>>> SegmentReader reader = getOnlySegmentReader(org.apach
>>>>> e.lucene.index.DirectoryReader.open(ram));
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>>> reader="+reader);
>>>>>
>>>>> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>>     org.apache.lucene.index.LeafReader sr =
>>>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>>>>> sr="+sr);
>>>>>
>>>>> //add term to SegmentReader postings
>>>>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>>>> PostingsEnum.PAYLOADS);
>>>>>
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>> postings="+postings);
>>>>>
>>>>> //display the parameters for collectLeaf method for query:
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>> position="+position);
>>>>>
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>> term1="+term1);
>>>>>     try
>>>>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>> postings, int position,       //org.apache.lucene.index.Term term) throws
>>>>> java.io.IOException {
>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>> }
>>>>> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>> IOException ="+ioe.getMessage()); }
>>>>>
>>>>> collectLeaf is the only method that compares
>>>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>>>
>>>>> to determine "match"
>>>>>
>>>>> unless of course match between individual payload and payloadToMatch
>>>>> is tested elsewhere ?
>>>>>
>>>>> WDYT?
>>>>> Martin
>>>>> ______________________________________________
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>> *Sent:* Saturday, April 29, 2017 7:58 PM
>>>>> *To:* Lucene/Solr dev
>>>>> *Subject:* Re: Release 6.6
>>>>>
>>>>> Martin -
>>>>>
>>>>> Interesting test but I couldn’t copy/paste it in to try it out as it
>>>>> uses some logging and APIs that aren’t already in the project and classpath
>>>>> of these lucene tests within that queries module (within IntelliJ, mind
>>>>> you).
>>>>>
>>>>> I was able to resolve the misunderstanding (and .equals/.hashCode
>>>>> bugs) so everything is working as expected with SpanPayloadCheckQuery for
>>>>> me now.   Do your tests point out an issue?   Or confirming that it is
>>>>> working properly at a lower level?
>>>>>
>>>>> Erik
>>>>>
>>>>>
>>>>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com>
>>>>> wrote:
>>>>>
>>>>> Martin Gainty has shared a OneDrive file with you. To view it, click
>>>>> the link below.
>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>> TestPayloadCheckQuery.java
>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>>> attached
>>>>>
>>>>> I coded this last nite so it is "quick and dirty"
>>>>>
>>>>> in any case let me know if  testSpanPayloadCheck()
>>>>> method modification properly addresses your situation
>>>>>
>>>>> Thanks!
>>>>> Martin
>>>>> ______________________________________________
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>> *Sent:* Saturday, April 29, 2017 8:58 AM
>>>>> *To:* dev@lucene.apache.org
>>>>> *Subject:* Re: Release 6.6
>>>>>
>>>>> Martin - there is a test class specifically for this query.   See the
>>>>> recent commits I've made to test it further fixing .equals/.hashCode and
>>>>> rewrite.
>>>>>
>>>>> Can you send your full test code?
>>>>>
>>>>>    Erik
>>>>>
>>>>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>>>>>
>>>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I
>>>>> was about to reply just run that TestCase
>>>>> (until i discovered there wasnt any!)
>>>>>
>>>>> i'll start the bidding at 1 dinar for TestCase org.apache.lucene
>>>>> .queries.payloads.TestPayloadCheckQuery mod:
>>>>>   @org.junit.Test
>>>>>   public void testSpanPayloadCheck() throws Exception
>>>>>
>>>>>
>>>>>     //now lets test the collectLeaf for query
>>>>>     //of course calling Base Class SpanPayloadCheckQuery to construct
>>>>> query
>>>>>
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>> postings="+postings);
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>> position="+position);
>>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259
>>>>> before query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>>>> term1="+term1);
>>>>>
>>>>>     try
>>>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>>> postings, int position,              //org.apache.lucene.index.Term
>>>>> term) throws java.io.IOException {
>>>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1);
>>>>> }
>>>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>>>> IOException ="+ioe.getMessage()); }
>>>>>
>>>>> unless of course anyone has a better idea to test collectLeaf ?
>>>>> Martin
>>>>> ______________________________________________
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------
>>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>>> *Sent:* Tuesday, April 25, 2017 7:57 PM
>>>>> *To:* dev@lucene.apache.org
>>>>> *Subject:* Re: Release 6.6
>>>>>
>>>>> Probably no bribe needed, but an updated patch would be a good start
>>>>> (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>>
>>>>> Erik
>>>>>
>>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
>>>>> wrote:
>>>>>
>>>>> Who do I have to bribe to get SOLR-629 included?
>>>>>
>>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>>
>>>>> wunder
>>>>> Walter Underwood
>>>>> wunder@wunderwood.org
>>>>> http://observer.wunderwood.org/  (my blog)
>>>>>
>>>>>
>>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>>> ichattopadhyaya@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like to
>>>>> propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0
>>>>> release).
>>>>>
>>>>> I can volunteer to release this, and I can cut the release branch
>>>>> around 4th May, in order to let some time for devs to finish current issues.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Regards,
>>>>> Ishan
>>>>>
>>>>>
>>>>>
>>>>
>>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Done, Adrien. Thanks!

On Thu, May 11, 2017 at 7:34 PM, Adrien Grand <jp...@gmail.com> wrote:

> Ishan, wdyt about running addVersion on the branch_6x/master as well? I
> think it would help realize that the 6.6 branch has been cut when looking
> at the CHANGES.txt file and not forget about backporting?
>
> Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> a écrit :
>
>> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
>> bugfixes to the branch, if needed.
>> Planning to build the first RC on 15 May. Please let me know if there are
>> any objections.
>>
>> Thanks,
>> Ishan
>>
>> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> Planning to cut the release branch in another 10-12 hours.
>>>
>>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>>> wrote:
>>>
>>>> i was wondering if there was a specific test for SpanPayloadCheckQuery
>>>> method
>>>>
>>>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>>
>>>>
>>>> the only implementation i could locate was in collectLeaf of
>>>> SpanPayloadCheckQuery
>>>>
>>>>
>>>> I will submit JIRA with Patch
>>>>
>>>>
>>>> as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
>>>> fragments (what we called phenomes) than current SEO implementations
>>>>
>>>>
>>>> Can you suggest a book to read to better understand Lucenes pattern
>>>> dissection and match algorithms?
>>>>
>>>>
>>>> Many Thanks for helpful guidance
>>>> Martin
>>>> ______________________________________________
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>>>
>>>> *To:* dev@lucene.apache.org
>>>> *Subject:* Re: Release 6.6
>>>>
>>>> Martin -
>>>>
>>>> I have to admit to still being unsure what the gist is here - is there
>>>> a bug?   Apologies for not catching what you’re saying/showing here.
>>>> Again, as far as I can tell SpanPayloadCheckQuery is working as expected
>>>> now.
>>>>
>>>> I’m going to focus purely on SOLR-1485 this week to get it committed
>>>> for 6.6.  If there is an issue to address with your work would you please
>>>> open a JIRA and include your patch there?
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>>
>>>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com> wrote:
>>>>
>>>> Mornin' Erik
>>>>
>>>> there is a collectLeaf  override in org.apache.lucene.queries.payloads.
>>>> TestPayloadSpans ..but its never called:
>>>>
>>>> static class VerifyingCollector implements SpanCollector {
>>>>     List<BytesRef> payloads = new ArrayList<>();
>>>>     @Override
>>>>     public void collectLeaf(PostingsEnum postings, int position, Term
>>>> term) throws IOException {
>>>>      ....
>>>>      }
>>>> }
>>>>
>>>>
>>>> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests
>>>> collectLeaf for query
>>>>
>>>> //initialise term
>>>>
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before
>>>> term1=new org.apache.lucene.index.Term('field','withPayload')");
>>>> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
>>>> "withPayload");
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>>> term1="+term1);
>>>>
>>>> //assume position is 5
>>>>     int position=5;
>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>>> position="+position);
>>>>
>>>>     BytesRef pay = new BytesRef("pos: " + position);
>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>>> pay="+pay);
>>>>
>>>> //build spanQuery with term parameter
>>>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>>> SpanTermQuery(term1);
>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>>> spanQuery1="+spanQuery1);
>>>>
>>>> //add BytesRef to payloadToMatch list
>>>>     java.util.List<org.apache.lucene.util.BytesRef> payloadToMatch=new
>>>> java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>>> payloadToMatch="+payloadToMatch);
>>>>     payloadToMatch.add(pay);
>>>>
>>>> //build SpanPayloadCheckQuery
>>>>
>>>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>>> (org.apache.lucene.search.spans.SpanQuery)query,
>>>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>>> query="+query);
>>>>
>>>> //build lucene Directory (TODO: we should use an existing directory
>>>> with REAL test-data)
>>>> org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.
>>>> randomizedtesting.RandomizedContext.current().getRandom());
>>>>
>>>> //build SegmentReader from Directory
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>>> ram="+ram);
>>>> SegmentReader reader = getOnlySegmentReader(org.apache.lucene.index.
>>>> DirectoryReader.open(ram));
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>>> reader="+reader);
>>>>
>>>> //populate SlowCompositeReaderWrapper with SegmentReader
>>>>     org.apache.lucene.index.LeafReader sr = org.apache.lucene.index.
>>>> SlowCompositeReaderWrapper.wrap(reader);
>>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>>>> sr="+sr);
>>>>
>>>> //add term to SegmentReader postings
>>>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>>> PostingsEnum.PAYLOADS);
>>>>
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> where postings="+postings);
>>>>
>>>> //display the parameters for collectLeaf method for query:
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> where position="+position);
>>>>
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> where term1="+term1);
>>>>     try
>>>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>> postings, int position,       //org.apache.lucene.index.Term term) throws
>>>> java.io.IOException {
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>> lucene.index.Term)term1);
>>>> }
>>>> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>
>>>> collectLeaf is the only method that compares matches=payloadToMatch.get(
>>>> upto).bytesEquals(payload)
>>>>
>>>> to determine "match"
>>>>
>>>> unless of course match between individual payload and payloadToMatch is
>>>> tested elsewhere ?
>>>>
>>>> WDYT?
>>>> Martin
>>>> ______________________________________________
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>> *Sent:* Saturday, April 29, 2017 7:58 PM
>>>> *To:* Lucene/Solr dev
>>>> *Subject:* Re: Release 6.6
>>>>
>>>> Martin -
>>>>
>>>> Interesting test but I couldn’t copy/paste it in to try it out as it
>>>> uses some logging and APIs that aren’t already in the project and classpath
>>>> of these lucene tests within that queries module (within IntelliJ, mind
>>>> you).
>>>>
>>>> I was able to resolve the misunderstanding (and .equals/.hashCode bugs)
>>>> so everything is working as expected with SpanPayloadCheckQuery for me now.
>>>>   Do your tests point out an issue?   Or confirming that it is working
>>>> properly at a lower level?
>>>>
>>>> Erik
>>>>
>>>>
>>>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com> wrote:
>>>>
>>>> Martin Gainty has shared a OneDrive file with you. To view it, click
>>>> the link below.
>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>> TestPayloadCheckQuery.java
>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>>> attached
>>>>
>>>> I coded this last nite so it is "quick and dirty"
>>>>
>>>> in any case let me know if  testSpanPayloadCheck() method modification
>>>> properly addresses your situation
>>>>
>>>> Thanks!
>>>> Martin
>>>> ______________________________________________
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>> *Sent:* Saturday, April 29, 2017 8:58 AM
>>>> *To:* dev@lucene.apache.org
>>>> *Subject:* Re: Release 6.6
>>>>
>>>> Martin - there is a test class specifically for this query.   See the
>>>> recent commits I've made to test it further fixing .equals/.hashCode and
>>>> rewrite.
>>>>
>>>> Can you send your full test code?
>>>>
>>>>    Erik
>>>>
>>>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>>>>
>>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was
>>>> about to reply just run that TestCase
>>>> (until i discovered there wasnt any!)
>>>>
>>>> i'll start the bidding at 1 dinar for TestCase org.apache.
>>>> lucene.queries.payloads.TestPayloadCheckQuery mod:
>>>>   @org.junit.Test
>>>>   public void testSpanPayloadCheck() throws Exception
>>>>
>>>>
>>>>     //now lets test the collectLeaf for query
>>>>     //of course calling Base Class SpanPayloadCheckQuery to construct
>>>> query
>>>>
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> where postings="+postings);
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> where position="+position);
>>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> where term1="+term1);
>>>>
>>>>     try
>>>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>>> postings, int position,              //org.apache.lucene.index.Term
>>>> term) throws java.io.IOException {
>>>> query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
>>>> lucene.index.Term)term1);
>>>> }
>>>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>>>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.
>>>> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
>>>> LINE 106 throws IOException ="+ioe.getMessage()); }
>>>>
>>>> unless of course anyone has a better idea to test collectLeaf ?
>>>> Martin
>>>> ______________________________________________
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------
>>>> *From:* Erik Hatcher <er...@gmail.com>
>>>> *Sent:* Tuesday, April 25, 2017 7:57 PM
>>>> *To:* dev@lucene.apache.org
>>>> *Subject:* Re: Release 6.6
>>>>
>>>> Probably no bribe needed, but an updated patch would be a good start
>>>> (or will the 2.5 year old patch still apply and be acceptable as-is?)
>>>>
>>>> Erik
>>>>
>>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
>>>> wrote:
>>>>
>>>> Who do I have to bribe to get SOLR-629 included?
>>>>
>>>> https://issues.apache.org/jira/browse/SOLR-629
>>>>
>>>> wunder
>>>> Walter Underwood
>>>> wunder@wunderwood.org
>>>> http://observer.wunderwood.org/  (my blog)
>>>>
>>>>
>>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>>> ichattopadhyaya@gmail.com> wrote:
>>>>
>>>> Hi,
>>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like to
>>>> propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0
>>>> release).
>>>>
>>>> I can volunteer to release this, and I can cut the release branch
>>>> around 4th May, in order to let some time for devs to finish current issues.
>>>>
>>>> What do you think?
>>>>
>>>> Regards,
>>>> Ishan
>>>>
>>>>
>>>>
>>>
>>

Re: Release 6.6

Posted by Adrien Grand <jp...@gmail.com>.
Ishan, wdyt about running addVersion on the branch_6x/master as well? I
think it would help realize that the 6.6 branch has been cut when looking
at the CHANGES.txt file and not forget about backporting?

Le mar. 9 mai 2017 à 17:58, Ishan Chattopadhyaya <ic...@gmail.com>
a écrit :

> I've cut the branch for 6.6. (branch_6_6). Please feel free to add
> bugfixes to the branch, if needed.
> Planning to build the first RC on 15 May. Please let me know if there are
> any objections.
>
> Thanks,
> Ishan
>
> On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> Planning to cut the release branch in another 10-12 hours.
>>
>> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com>
>> wrote:
>>
>>> i was wondering if there was a specific test for SpanPayloadCheckQuery
>>> method
>>>
>>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>>
>>>
>>> the only implementation i could locate was in collectLeaf of
>>> SpanPayloadCheckQuery
>>>
>>>
>>> I will submit JIRA with Patch
>>>
>>>
>>> as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
>>> fragments (what we called phenomes) than current SEO implementations
>>>
>>>
>>> Can you suggest a book to read to better understand Lucenes pattern
>>> dissection and match algorithms?
>>>
>>>
>>> Many Thanks for helpful guidance
>>> Martin
>>> ______________________________________________
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Erik Hatcher <er...@gmail.com>
>>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>>
>>> *To:* dev@lucene.apache.org
>>> *Subject:* Re: Release 6.6
>>>
>>> Martin -
>>>
>>> I have to admit to still being unsure what the gist is here - is there a
>>> bug?   Apologies for not catching what you’re saying/showing here.  Again,
>>> as far as I can tell SpanPayloadCheckQuery is working as expected now.
>>>
>>> I’m going to focus purely on SOLR-1485 this week to get it committed for
>>> 6.6.  If there is an issue to address with your work would you please open
>>> a JIRA and include your patch there?
>>>
>>> Thanks,
>>> Erik
>>>
>>>
>>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com> wrote:
>>>
>>> Mornin' Erik
>>>
>>> there is a collectLeaf  override in org.apache.lucene.queries.payloads.TestPayloadSpans
>>> ..but its never called:
>>>
>>> static class VerifyingCollector implements SpanCollector {
>>>     List<BytesRef> payloads = new ArrayList<>();
>>>     @Override
>>>     public void collectLeaf(PostingsEnum postings, int position, Term
>>> term) throws IOException {
>>>      ....
>>>      }
>>> }
>>>
>>>
>>> the modification in
>>> org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests collectLeaf
>>> for query
>>>
>>> //initialise term
>>>
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before
>>> term1=new org.apache.lucene.index.Term('field','withPayload')");
>>> org.apache.lucene.index.Term term1=new
>>> org.apache.lucene.index.Term("field", "withPayload");
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>>> term1="+term1);
>>>
>>> //assume position is 5
>>>     int position=5;
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>>> position="+position);
>>>
>>>     BytesRef pay = new BytesRef("pos: " + position);
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>>> pay="+pay);
>>>
>>> //build spanQuery with term parameter
>>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>>> SpanTermQuery(term1);
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>>> spanQuery1="+spanQuery1);
>>>
>>> //add BytesRef to payloadToMatch list
>>>     java.util.List<org.apache.lucene.util.BytesRef> payloadToMatch=new
>>> java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>>> payloadToMatch="+payloadToMatch);
>>>     payloadToMatch.add(pay);
>>>
>>> //build SpanPayloadCheckQuery
>>>
>>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>>> (org.apache.lucene.search.spans.SpanQuery)query,
>>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>>> query="+query);
>>>
>>> //build lucene Directory (TODO: we should use an existing directory with
>>> REAL test-data)
>>> org.apache.lucene.store.Directory ram =
>>> newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());
>>>
>>> //build SegmentReader from Directory
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>>> ram="+ram);
>>> SegmentReader reader =
>>> getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>>> reader="+reader);
>>>
>>> //populate SlowCompositeReaderWrapper with SegmentReader
>>>     org.apache.lucene.index.LeafReader sr =
>>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>>> sr="+sr);
>>>
>>> //add term to SegmentReader postings
>>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>>> PostingsEnum.PAYLOADS);
>>>
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> postings="+postings);
>>>
>>> //display the parameters for collectLeaf method for query:
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> position="+position);
>>>
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>     try
>>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>>> postings, int position,       //org.apache.lucene.index.Term term) throws
>>> java.io.IOException {
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1);
>>> }
>>> catch(java.io.IOException ioe) {
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>> IOException ="+ioe.getMessage()); }
>>>
>>> collectLeaf is the only method that compares
>>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>>
>>> to determine "match"
>>>
>>> unless of course match between individual payload and payloadToMatch is
>>> tested elsewhere ?
>>>
>>> WDYT?
>>> Martin
>>> ______________________________________________
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Erik Hatcher <er...@gmail.com>
>>> *Sent:* Saturday, April 29, 2017 7:58 PM
>>> *To:* Lucene/Solr dev
>>> *Subject:* Re: Release 6.6
>>>
>>> Martin -
>>>
>>> Interesting test but I couldn’t copy/paste it in to try it out as it
>>> uses some logging and APIs that aren’t already in the project and classpath
>>> of these lucene tests within that queries module (within IntelliJ, mind
>>> you).
>>>
>>> I was able to resolve the misunderstanding (and .equals/.hashCode bugs)
>>> so everything is working as expected with SpanPayloadCheckQuery for me now.
>>>   Do your tests point out an issue?   Or confirming that it is working
>>> properly at a lower level?
>>>
>>> Erik
>>>
>>>
>>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com> wrote:
>>>
>>> Martin Gainty has shared a OneDrive file with you. To view it, click the
>>> link below.
>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>> TestPayloadCheckQuery.java
>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>>> attached
>>>
>>> I coded this last nite so it is "quick and dirty"
>>>
>>> in any case let me know if  testSpanPayloadCheck() method modification
>>> properly addresses your situation
>>>
>>> Thanks!
>>> Martin
>>> ______________________________________________
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Erik Hatcher <er...@gmail.com>
>>> *Sent:* Saturday, April 29, 2017 8:58 AM
>>> *To:* dev@lucene.apache.org
>>> *Subject:* Re: Release 6.6
>>>
>>> Martin - there is a test class specifically for this query.   See the
>>> recent commits I've made to test it further fixing .equals/.hashCode and
>>> rewrite.
>>>
>>> Can you send your full test code?
>>>
>>>    Erik
>>>
>>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>>>
>>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was
>>> about to reply just run that TestCase
>>> (until i discovered there wasnt any!)
>>>
>>> i'll start the bidding at 1 dinar for TestCase org.apache.lucene.queries.payloads.TestPayloadCheckQuery
>>> mod:
>>>   @org.junit.Test
>>>   public void testSpanPayloadCheck() throws Exception
>>>
>>>
>>>     //now lets test the collectLeaf for query
>>>     //of course calling Base Class SpanPayloadCheckQuery to construct
>>> query
>>>
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> postings="+postings);
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where
>>> position="+position);
>>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>>
>>>     try
>>>     { //test public void
>>> collectLeaf(org.apache.lucene.index.PostingsEnum postings, int position,
>>>            //org.apache.lucene.index.Term term) throws java.io.IOException {
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1);
>>> }
>>> catch(java.io.IOException ioe) {
>>> log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264
>>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>>> IOException ="+ioe.getMessage()); }
>>>
>>> unless of course anyone has a better idea to test collectLeaf ?
>>> Martin
>>> ______________________________________________
>>>
>>>
>>>
>>>
>>> ------------------------------
>>> *From:* Erik Hatcher <er...@gmail.com>
>>> *Sent:* Tuesday, April 25, 2017 7:57 PM
>>> *To:* dev@lucene.apache.org
>>> *Subject:* Re: Release 6.6
>>>
>>> Probably no bribe needed, but an updated patch would be a good start (or
>>> will the 2.5 year old patch still apply and be acceptable as-is?)
>>>
>>> Erik
>>>
>>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
>>> wrote:
>>>
>>> Who do I have to bribe to get SOLR-629 included?
>>>
>>> https://issues.apache.org/jira/browse/SOLR-629
>>>
>>> wunder
>>> Walter Underwood
>>> wunder@wunderwood.org
>>> http://observer.wunderwood.org/  (my blog)
>>>
>>>
>>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>>> ichattopadhyaya@gmail.com> wrote:
>>>
>>> Hi,
>>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like to
>>> propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0
>>> release).
>>>
>>> I can volunteer to release this, and I can cut the release branch around
>>> 4th May, in order to let some time for devs to finish current issues.
>>>
>>> What do you think?
>>>
>>> Regards,
>>> Ishan
>>>
>>>
>>>
>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
I've cut the branch for 6.6. (branch_6_6). Please feel free to add bugfixes
to the branch, if needed.
Planning to build the first RC on 15 May. Please let me know if there are
any objections.

Thanks,
Ishan

On Tue, May 9, 2017 at 11:10 AM, Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> Planning to cut the release branch in another 10-12 hours.
>
> On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
>> i was wondering if there was a specific test for SpanPayloadCheckQuery
>> method
>>
>> matches = payloadToMatch.get(upto).bytesEquals(payload);
>>
>>
>> the only implementation i could locate was in collectLeaf of
>> SpanPayloadCheckQuery
>>
>>
>> I will submit JIRA with Patch
>>
>>
>> as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
>> fragments (what we called phenomes) than current SEO implementations
>>
>>
>> Can you suggest a book to read to better understand Lucenes pattern
>> dissection and match algorithms?
>>
>>
>> Many Thanks for helpful guidance
>> Martin
>> ______________________________________________
>>
>>
>>
>>
>> ------------------------------
>> *From:* Erik Hatcher <er...@gmail.com>
>> *Sent:* Sunday, April 30, 2017 2:06 PM
>>
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Release 6.6
>>
>> Martin -
>>
>> I have to admit to still being unsure what the gist is here - is there a
>> bug?   Apologies for not catching what you’re saying/showing here.  Again,
>> as far as I can tell SpanPayloadCheckQuery is working as expected now.
>>
>> I’m going to focus purely on SOLR-1485 this week to get it committed for
>> 6.6.  If there is an issue to address with your work would you please open
>> a JIRA and include your patch there?
>>
>> Thanks,
>> Erik
>>
>>
>> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com> wrote:
>>
>> Mornin' Erik
>>
>> there is a collectLeaf  override in org.apache.lucene.queries.payloads.
>> TestPayloadSpans ..but its never called:
>>
>> static class VerifyingCollector implements SpanCollector {
>>     List<BytesRef> payloads = new ArrayList<>();
>>     @Override
>>     public void collectLeaf(PostingsEnum postings, int position, Term
>> term) throws IOException {
>>      ....
>>      }
>> }
>>
>>
>> the modification in org.apache.lucene.queries.payl
>> oads.TestPayloadCheckQuery tests collectLeaf for query
>>
>> //initialise term
>>
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before
>> term1=new org.apache.lucene.index.Term('field','withPayload')");
>> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
>> "withPayload");
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
>> term1="+term1);
>>
>> //assume position is 5
>>     int position=5;
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
>> position="+position);
>>
>>     BytesRef pay = new BytesRef("pos: " + position);
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
>> pay="+pay);
>>
>> //build spanQuery with term parameter
>>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
>> SpanTermQuery(term1);
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
>> spanQuery1="+spanQuery1);
>>
>> //add BytesRef to payloadToMatch list
>>     java.util.List<org.apache.lucene.util.BytesRef> payloadToMatch=new
>> java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
>> payloadToMatch="+payloadToMatch);
>>     payloadToMatch.add(pay);
>>
>> //build SpanPayloadCheckQuery
>>
>> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
>> (org.apache.lucene.search.spans.SpanQuery)query,
>> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
>> query="+query);
>>
>> //build lucene Directory (TODO: we should use an existing directory with
>> REAL test-data)
>> org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.
>> randomizedtesting.RandomizedContext.current().getRandom());
>>
>> //build SegmentReader from Directory
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
>> ram="+ram);
>> SegmentReader reader = getOnlySegmentReader(org.apach
>> e.lucene.index.DirectoryReader.open(ram));
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
>> reader="+reader);
>>
>> //populate SlowCompositeReaderWrapper with SegmentReader
>>     org.apache.lucene.index.LeafReader sr =
>> org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
>>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
>> sr="+sr);
>>
>> //add term to SegmentReader postings
>> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
>> PostingsEnum.PAYLOADS);
>>
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> postings="+postings);
>>
>> //display the parameters for collectLeaf method for query:
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> position="+position);
>>
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>     try
>>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
>> postings, int position,       //org.apache.lucene.index.Term term) throws
>> java.io.IOException {
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1);
>> }
>> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>> IOException ="+ioe.getMessage()); }
>>
>> collectLeaf is the only method that compares
>> matches=payloadToMatch.get(upto).bytesEquals(payload)
>>
>> to determine "match"
>>
>> unless of course match between individual payload and payloadToMatch is
>> tested elsewhere ?
>>
>> WDYT?
>> Martin
>> ______________________________________________
>>
>>
>>
>>
>> ------------------------------
>> *From:* Erik Hatcher <er...@gmail.com>
>> *Sent:* Saturday, April 29, 2017 7:58 PM
>> *To:* Lucene/Solr dev
>> *Subject:* Re: Release 6.6
>>
>> Martin -
>>
>> Interesting test but I couldn’t copy/paste it in to try it out as it uses
>> some logging and APIs that aren’t already in the project and classpath of
>> these lucene tests within that queries module (within IntelliJ, mind you).
>>
>> I was able to resolve the misunderstanding (and .equals/.hashCode bugs)
>> so everything is working as expected with SpanPayloadCheckQuery for me now.
>>   Do your tests point out an issue?   Or confirming that it is working
>> properly at a lower level?
>>
>> Erik
>>
>>
>> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com> wrote:
>>
>> Martin Gainty has shared a OneDrive file with you. To view it, click the
>> link below.
>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>> TestPayloadCheckQuery.java
>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
>> attached
>>
>> I coded this last nite so it is "quick and dirty"
>>
>> in any case let me know if  testSpanPayloadCheck() method modification
>> properly addresses your situation
>>
>> Thanks!
>> Martin
>> ______________________________________________
>>
>>
>>
>>
>> ------------------------------
>> *From:* Erik Hatcher <er...@gmail.com>
>> *Sent:* Saturday, April 29, 2017 8:58 AM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Release 6.6
>>
>> Martin - there is a test class specifically for this query.   See the
>> recent commits I've made to test it further fixing .equals/.hashCode and
>> rewrite.
>>
>> Can you send your full test code?
>>
>>    Erik
>>
>> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>>
>> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was
>> about to reply just run that TestCase
>> (until i discovered there wasnt any!)
>>
>> i'll start the bidding at 1 dinar for TestCase org.apache.lucene
>> .queries.payloads.TestPayloadCheckQuery mod:
>>   @org.junit.Test
>>   public void testSpanPayloadCheck() throws Exception
>>
>>
>>     //now lets test the collectLeaf for query
>>     //of course calling Base Class SpanPayloadCheckQuery to construct
>> query
>>
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> postings="+postings);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where
>> position="+position);
>> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
>>
>>     try
>>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
>> postings, int position,              //org.apache.lucene.index.Term
>> term) throws java.io.IOException {
>> query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1);
>> }
>> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
>> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
>> (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws
>> IOException ="+ioe.getMessage()); }
>>
>> unless of course anyone has a better idea to test collectLeaf ?
>> Martin
>> ______________________________________________
>>
>>
>>
>>
>> ------------------------------
>> *From:* Erik Hatcher <er...@gmail.com>
>> *Sent:* Tuesday, April 25, 2017 7:57 PM
>> *To:* dev@lucene.apache.org
>> *Subject:* Re: Release 6.6
>>
>> Probably no bribe needed, but an updated patch would be a good start (or
>> will the 2.5 year old patch still apply and be acceptable as-is?)
>>
>> Erik
>>
>> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
>> wrote:
>>
>> Who do I have to bribe to get SOLR-629 included?
>>
>> https://issues.apache.org/jira/browse/SOLR-629
>>
>> wunder
>> Walter Underwood
>> wunder@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>>
>> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>> Hi,
>> We have lots of changes, optimizations, bug fixes for 6.6. I'd like to
>> propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0
>> release).
>>
>> I can volunteer to release this, and I can cut the release branch around
>> 4th May, in order to let some time for devs to finish current issues.
>>
>> What do you think?
>>
>> Regards,
>> Ishan
>>
>>
>>
>

Re: Release 6.6

Posted by Ishan Chattopadhyaya <ic...@gmail.com>.
Planning to cut the release branch in another 10-12 hours.

On Mon, May 1, 2017 at 4:00 PM, Martin Gainty <mg...@hotmail.com> wrote:

> i was wondering if there was a specific test for SpanPayloadCheckQuery
> method
>
> matches = payloadToMatch.get(upto).bytesEquals(payload);
>
>
> the only implementation i could locate was in collectLeaf of
> SpanPayloadCheckQuery
>
>
> I will submit JIRA with Patch
>
>
> as a CS *dinosaur* I am more familiar with LISP for dissecting sentence
> fragments (what we called phenomes) than current SEO implementations
>
>
> Can you suggest a book to read to better understand Lucenes pattern
> dissection and match algorithms?
>
>
> Many Thanks for helpful guidance
> Martin
> ______________________________________________
>
>
>
>
> ------------------------------
> *From:* Erik Hatcher <er...@gmail.com>
> *Sent:* Sunday, April 30, 2017 2:06 PM
>
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release 6.6
>
> Martin -
>
> I have to admit to still being unsure what the gist is here - is there a
> bug?   Apologies for not catching what you’re saying/showing here.  Again,
> as far as I can tell SpanPayloadCheckQuery is working as expected now.
>
> I’m going to focus purely on SOLR-1485 this week to get it committed for
> 6.6.  If there is an issue to address with your work would you please open
> a JIRA and include your patch there?
>
> Thanks,
> Erik
>
>
> On Apr 30, 2017, at 7:47 AM, Martin Gainty <mg...@hotmail.com> wrote:
>
> Mornin' Erik
>
> there is a collectLeaf  override in org.apache.lucene.queries.payloads.
> TestPayloadSpans ..but its never called:
>
> static class VerifyingCollector implements SpanCollector {
>     List<BytesRef> payloads = new ArrayList<>();
>     @Override
>     public void collectLeaf(PostingsEnum postings, int position, Term
> term) throws IOException {
>      ....
>      }
> }
>
>
> the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery tests
> collectLeaf for query
>
> //initialise term
>
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before
> term1=new org.apache.lucene.index.Term('field','withPayload')");
> org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field",
> "withPayload");
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233
> term1="+term1);
>
> //assume position is 5
>     int position=5;
>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235
> position="+position);
>
>     BytesRef pay = new BytesRef("pos: " + position);
>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237
> pay="+pay);
>
> //build spanQuery with term parameter
>     org.apache.lucene.search.spans.SpanQuery spanQuery1 = new
> SpanTermQuery(term1);
>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239
> spanQuery1="+spanQuery1);
>
> //add BytesRef to payloadToMatch list
>     java.util.List<org.apache.lucene.util.BytesRef> payloadToMatch=new
> java.util.ArrayList<org.apache.lucene.util.BytesRef>();
>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241
> payloadToMatch="+payloadToMatch);
>     payloadToMatch.add(pay);
>
> //build SpanPayloadCheckQuery
>
> query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
> (org.apache.lucene.search.spans.SpanQuery)query,
> (java.util.List<org.apache.lucene.util.BytesRef>)payloadToMatch);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249
> query="+query);
>
> //build lucene Directory (TODO: we should use an existing directory with
> REAL test-data)
> org.apache.lucene.store.Directory ram = newDirectory(com.carrotsearch.
> randomizedtesting.RandomizedContext.current().getRandom());
>
> //build SegmentReader from Directory
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251
> ram="+ram);
> SegmentReader reader = getOnlySegmentReader(org.apache.lucene.index.
> DirectoryReader.open(ram));
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253
> reader="+reader);
>
> //populate SlowCompositeReaderWrapper with SegmentReader
>     org.apache.lucene.index.LeafReader sr = org.apache.lucene.index.
> SlowCompositeReaderWrapper.wrap(reader);
>     log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255
> sr="+sr);
>
> //add term to SegmentReader postings
> org.apache.lucene.index.PostingsEnum postings = sr.postings(term1,
> PostingsEnum.PAYLOADS);
>
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where postings="+postings);
>
> //display the parameters for collectLeaf method for query:
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where position="+position);
>
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where term1="+term1);
>     try
>     { //public void collectLeaf(org.apache.lucene.index.PostingsEnum
> postings, int position,       //org.apache.lucene.index.Term term) throws
> java.io.IOException {
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
> lucene.index.Term)term1);
> }
> catch(java.io.IOException ioe) { log.debug("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> LINE 106 throws IOException ="+ioe.getMessage()); }
>
> collectLeaf is the only method that compares matches=payloadToMatch.get(
> upto).bytesEquals(payload)
>
> to determine "match"
>
> unless of course match between individual payload and payloadToMatch is
> tested elsewhere ?
>
> WDYT?
> Martin
> ______________________________________________
>
>
>
>
> ------------------------------
> *From:* Erik Hatcher <er...@gmail.com>
> *Sent:* Saturday, April 29, 2017 7:58 PM
> *To:* Lucene/Solr dev
> *Subject:* Re: Release 6.6
>
> Martin -
>
> Interesting test but I couldn’t copy/paste it in to try it out as it uses
> some logging and APIs that aren’t already in the project and classpath of
> these lucene tests within that queries module (within IntelliJ, mind you).
>
> I was able to resolve the misunderstanding (and .equals/.hashCode bugs) so
> everything is working as expected with SpanPayloadCheckQuery for me now.
> Do your tests point out an issue?   Or confirming that it is working
> properly at a lower level?
>
> Erik
>
>
> On Apr 29, 2017, at 9:08 AM, Martin Gainty <mg...@hotmail.com> wrote:
>
> Martin Gainty has shared a OneDrive file with you. To view it, click the
> link below.
> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
> TestPayloadCheckQuery.java
> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
> <https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
> attached
>
> I coded this last nite so it is "quick and dirty"
>
> in any case let me know if  testSpanPayloadCheck() method modification
> properly addresses your situation
>
> Thanks!
> Martin
> ______________________________________________
>
>
>
>
> ------------------------------
> *From:* Erik Hatcher <er...@gmail.com>
> *Sent:* Saturday, April 29, 2017 8:58 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release 6.6
>
> Martin - there is a test class specifically for this query.   See the
> recent commits I've made to test it further fixing .equals/.hashCode and
> rewrite.
>
> Can you send your full test code?
>
>    Erik
>
> On Apr 29, 2017, at 07:32, Martin Gainty <mg...@hotmail.com> wrote:
>
> when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was
> about to reply just run that TestCase
> (until i discovered there wasnt any!)
>
> i'll start the bidding at 1 dinar for TestCase org.apache.
> lucene.queries.payloads.TestPayloadCheckQuery mod:
>   @org.junit.Test
>   public void testSpanPayloadCheck() throws Exception
>
>
>     //now lets test the collectLeaf for query
>     //of course calling Base Class SpanPayloadCheckQuery to construct query
>
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where postings="+postings);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where position="+position);
> log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> where term1="+term1);
>
>     try
>     { //test public void collectLeaf(org.apache.lucene.index.PostingsEnum
> postings, int position,              //org.apache.lucene.index.Term term)
> throws java.io.IOException {
> query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.
> lucene.index.Term)term1);
> }
> catch(java.io.IOException ioe) { log.error("TestPayloadCheckQuery::testSpanPayloadCheck
> LINE 264 query.getPayloadChecker().collectLeaf((org.apache.
> lucene.index.PostingsEnum)postings, (int)position,(org.apache.lucene.index.Term)term1)
> LINE 106 throws IOException ="+ioe.getMessage()); }
>
> unless of course anyone has a better idea to test collectLeaf ?
> Martin
> ______________________________________________
>
>
>
>
> ------------------------------
> *From:* Erik Hatcher <er...@gmail.com>
> *Sent:* Tuesday, April 25, 2017 7:57 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release 6.6
>
> Probably no bribe needed, but an updated patch would be a good start (or
> will the 2.5 year old patch still apply and be acceptable as-is?)
>
> Erik
>
> On Apr 25, 2017, at 7:52 PM, Walter Underwood <wu...@wunderwood.org>
> wrote:
>
> Who do I have to bribe to get SOLR-629 included?
>
> https://issues.apache.org/jira/browse/SOLR-629
>
> wunder
> Walter Underwood
> wunder@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>
> On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
> Hi,
> We have lots of changes, optimizations, bug fixes for 6.6. I'd like to
> propose a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0
> release).
>
> I can volunteer to release this, and I can cut the release branch around
> 4th May, in order to let some time for devs to finish current issues.
>
> What do you think?
>
> Regards,
> Ishan
>
>
>