[jira] [Commented] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671481#comment-16671481 ] Tapan Vaishnav commented on LUCENE-8424: Hi [~romseygeek], Do you have any updates for this issue?? > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, > LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8424) Payload null value exception handling
[
https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588244#comment-16588244
]
Tapan Vaishnav commented on LUCENE-8424:
Hello [~romseygeek],
Thanks for your reply.
{quote}apologies for the delay in responding, I've been away on holiday for the
past few weeks.
{quote}
No worries, apologies from my side too for tagging you while you were on
holidays.
{quote}Rather than deciding in the parent query what to do with null payloads,
instead we should allow consumers to decide this directly.
{quote}
It's only one example but if I understood correctly, handling _null_ exception
in _docscore_ function(Consumer).
[https://github.com/apache/lucene-solr/blob/branch_7_3/lucene/queries/src/java/org/apache/lucene/queries/payloads/MinPayloadFunction.java#L35]
{noformat}
@Override
public float docScore(int docId, String field, int numPayloadsSeen, float
payloadScore) {
return numPayloadsSeen > 0 ? (payloadScore >0 ? payloadScore : 1) : 1;
}{noformat}
{quote}'ll upload an example patch soonish which should explain what I mean.
{quote}
Got it, Thank you.
> Payload null value exception handling
> -
>
> Key: LUCENE-8424
> URL: https://issues.apache.org/jira/browse/LUCENE-8424
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2, 7.3.1
>Reporter: Tapan Vaishnav
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch,
> LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch
>
>
> If-Condition to check payload null value in _PayloadScoreQuery.java_ was
> removed in LUCENE-8038. Because of that, regarding of the payload value,
> _payloadsSeen_ is always getting increment. This has compromised the overall
> score of the document(for instance, as payloadSeens is always greater than 0,
> docScore() in _MinPayloadFunction.java_ only returns payloadScore which can
> be zero depending on the payload value). Ideally, it should've returned 1 in
> case of _payload==null_.
> I have added a simple patch to get started, Please let me know if it needs
> any improvements.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tapan Vaishnav updated LUCENE-8424: --- Attachment: LUCENE-8424.patch > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, > LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tapan Vaishnav updated LUCENE-8424: --- Attachment: LUCENE-8424.patch > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, > LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tapan Vaishnav updated LUCENE-8424: --- Attachment: LUCENE-8424.patch > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, > LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tapan Vaishnav updated LUCENE-8424: --- Attachment: LUCENE-8424.patch > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch, > LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16571383#comment-16571383 ] Tapan Vaishnav commented on LUCENE-8424: Hi [~romseygeek] I would really appreciate if you could provide some feedback regarding the patch. Sorry to bother you in your busy schedule. Thanks in advance. > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tapan Vaishnav updated LUCENE-8424: --- Attachment: LUCENE-8424.patch > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16559321#comment-16559321 ] Tapan Vaishnav commented on LUCENE-8424: Hi [~romseygeek], I have added the updated patch. After changing the payload value for the second query term as null, AveragePayloadFunction and MinPayloadFunction scores have been changed and updated accordingly. Also, the If-Condition has been put in a more appropriate position. Please have a look and let me know if this needs any changes. Thanks in advance. > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tapan Vaishnav updated LUCENE-8424: --- Attachment: LUCENE-8424.patch > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Assignee: Alan Woodward >Priority: Minor > Attachments: LUCENE-8424.patch, LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8424) Payload null value exception handling
[
https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16554222#comment-16554222
]
Tapan Vaishnav commented on LUCENE-8424:
Hi [~romseygeek],
Thanks for your quick response.
{quote}We can't just return immediately when the payload is null, due to
LUCENE-7744.
{quote}
I see, thanks for pointing it out. I will change accordingly.
{quote}It would also be good to add a test to TestPayloadScoreQuery that checks
behaviour when some and/or all payloads are null.{quote}
I tried doing so in TestPayloadScoreQuery but couldn't quite figure out where
to look for, I will try again to add some test cases.
> Payload null value exception handling
> -
>
> Key: LUCENE-8424
> URL: https://issues.apache.org/jira/browse/LUCENE-8424
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 7.2, 7.3.1
>Reporter: Tapan Vaishnav
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-8424.patch
>
>
> If-Condition to check payload null value in _PayloadScoreQuery.java_ was
> removed in LUCENE-8038. Because of that, regarding of the payload value,
> _payloadsSeen_ is always getting increment. This has compromised the overall
> score of the document(for instance, as payloadSeens is always greater than 0,
> docScore() in _MinPayloadFunction.java_ only returns payloadScore which can
> be zero depending on the payload value). Ideally, it should've returned 1 in
> case of _payload==null_.
> I have added a simple patch to get started, Please let me know if it needs
> any improvements.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8424) Payload null value exception handling
[ https://issues.apache.org/jira/browse/LUCENE-8424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tapan Vaishnav updated LUCENE-8424: --- Attachment: LUCENE-8424.patch > Payload null value exception handling > - > > Key: LUCENE-8424 > URL: https://issues.apache.org/jira/browse/LUCENE-8424 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.2, 7.3.1 >Reporter: Tapan Vaishnav >Priority: Minor > Attachments: LUCENE-8424.patch > > > If-Condition to check payload null value in _PayloadScoreQuery.java_ was > removed in LUCENE-8038. Because of that, regarding of the payload value, > _payloadsSeen_ is always getting increment. This has compromised the overall > score of the document(for instance, as payloadSeens is always greater than 0, > docScore() in _MinPayloadFunction.java_ only returns payloadScore which can > be zero depending on the payload value). Ideally, it should've returned 1 in > case of _payload==null_. > I have added a simple patch to get started, Please let me know if it needs > any improvements. > Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8424) Payload null value exception handling
Tapan Vaishnav created LUCENE-8424: -- Summary: Payload null value exception handling Key: LUCENE-8424 URL: https://issues.apache.org/jira/browse/LUCENE-8424 Project: Lucene - Core Issue Type: Bug Affects Versions: 7.3.1, 7.2 Reporter: Tapan Vaishnav If-Condition to check payload null value in _PayloadScoreQuery.java_ was removed in LUCENE-8038. Because of that, regarding of the payload value, _payloadsSeen_ is always getting increment. This has compromised the overall score of the document(for instance, as payloadSeens is always greater than 0, docScore() in _MinPayloadFunction.java_ only returns payloadScore which can be zero depending on the payload value). Ideally, it should've returned 1 in case of _payload==null_. I have added a simple patch to get started, Please let me know if it needs any improvements. Thanks in advance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8038) Decouple payload decoding from Similarity
[ https://issues.apache.org/jira/browse/LUCENE-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552852#comment-16552852 ] Tapan Vaishnav commented on LUCENE-8038: Hi [~romseygeek] , Thank you for your quick response. I will open a new JIRA issue concerning this bug. > Decouple payload decoding from Similarity > - > > Key: LUCENE-8038 > URL: https://issues.apache.org/jira/browse/LUCENE-8038 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.2 > > Attachments: LUCENE-8038-master.patch, LUCENE-8038.patch > > > PayloadScoreQuery is the only place that currently uses > SimScorer.computePayloadFactor(), and as discussed on LUCENE-8014, this seems > like the wrong place for it. We should instead add a PayloadDecoder > abstraction that is passed to PayloadScoreQuery. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8038) Decouple payload decoding from Similarity
[
https://issues.apache.org/jira/browse/LUCENE-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552374#comment-16552374
]
Tapan Vaishnav edited comment on LUCENE-8038 at 7/23/18 6:19 AM:
-
[~romseygeek]
Hello,
Can you(or anyone) tell me about the motivation behind removing the following
if-condition?
Java class:
/lucene/queries/src/java/org/apache/lucene/queries/payloads/PayloadScoreQuery.java
{noformat}if (payload == null)
return;{noformat}
Actually, in our custom query parser, payload value is null and earlier it was
getting skipped and PayloadsSeen was 0 but now function is returning
PayloadsSeen as 1 and the overall score is getting compromised.
Thanks in advance.
was (Author: tvaishna):
[~romseygeek]
Hello,
Can you(or anyone) tell me what was the motive behind removing this
if-condition?
Java class:
/lucene/queries/src/java/org/apache/lucene/queries/payloads/PayloadScoreQuery.java
{noformat}if (payload == null)
return;{noformat}
Actually, in our custom query parser, payload value is null and earlier it was
getting skipped and PayloadsSeen was 0 but now function is returning
PayloadsSeen as 1 and the overall score is getting compromised.
Thanks in advance.
> Decouple payload decoding from Similarity
> -
>
> Key: LUCENE-8038
> URL: https://issues.apache.org/jira/browse/LUCENE-8038
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.2
>
> Attachments: LUCENE-8038-master.patch, LUCENE-8038.patch
>
>
> PayloadScoreQuery is the only place that currently uses
> SimScorer.computePayloadFactor(), and as discussed on LUCENE-8014, this seems
> like the wrong place for it. We should instead add a PayloadDecoder
> abstraction that is passed to PayloadScoreQuery.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8038) Decouple payload decoding from Similarity
[
https://issues.apache.org/jira/browse/LUCENE-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552374#comment-16552374
]
Tapan Vaishnav commented on LUCENE-8038:
[~romseygeek]
Hello,
Can you(or anyone) tell me what was the motive behind removing this
if-condition?
Java class:
/lucene/queries/src/java/org/apache/lucene/queries/payloads/PayloadScoreQuery.java
{noformat}if (payload == null)
return;{noformat}
Actually, in our custom query parser, payload value is null and earlier it was
getting skipped and PayloadsSeen was 0 but now function is returning
PayloadsSeen as 1 and the overall score is getting compromised.
Thanks in advance.
> Decouple payload decoding from Similarity
> -
>
> Key: LUCENE-8038
> URL: https://issues.apache.org/jira/browse/LUCENE-8038
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.2
>
> Attachments: LUCENE-8038-master.patch, LUCENE-8038.patch
>
>
> PayloadScoreQuery is the only place that currently uses
> SimScorer.computePayloadFactor(), and as discussed on LUCENE-8014, this seems
> like the wrong place for it. We should instead add a PayloadDecoder
> abstraction that is passed to PayloadScoreQuery.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16436784#comment-16436784
]
Tapan Vaishnav commented on SOLR-11913:
---
I see, how come it didn't show anything in the following report?
https://issues.apache.org/jira/browse/SOLR-11913?focusedCommentId=16428288&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16428288
Also, apologies that you had to most of the work.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16436723#comment-16436723
]
Tapan Vaishnav commented on SOLR-11913:
---
bq.Sure; I'll re-order that. There is no real code rule about that here; I just
try to maintain some semblance of some sort of organization that feels
reasonable and not haphazard.
I see.
bq.Thanks for helping out. I'll expect to commit soon after the tests pass.
(y)
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16436519#comment-16436519
]
Tapan Vaishnav commented on SOLR-11913:
---
[~dsmiley]
Thanks for the updated patch.
{quote}Added more Javadocs, not just to the new methods here
{quote}
Thanks for the Javadocs, I'll keep in mind about the manner from next time
onwards.
{quote}added a convenience method: public Stream>
stream()
{quote}
We are not using the _Override_ annotation for the stream function, so isn't
it better to re-order it about the iterator function for better code style?
Thank you for all your feedbacks, there were really helpful.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Labels: newdev
> Fix For: 7.4
>
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424994#comment-16424994
]
Tapan Vaishnav commented on SOLR-11913:
---
[~dsmiley] Thanks for your reply.
I have updated few getParameterNamesiterator() callers and fixed some bugs into
the latest patch.
Please have a look and let me know your thoughts.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tapan Vaishnav updated SOLR-11913:
--
Attachment: SOLR-11913.patch
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913.patch,
> SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16411026#comment-16411026
]
Tapan Vaishnav edited comment on SOLR-11913 at 3/23/18 8:50 AM:
{quote}The default impl can produce a Map.Entry with a getValue that calls
through to getParams.
{quote}
This I didn't think of. Thanks for pointing it out, have fixed now and will
upload with the latest patch.
I have fixed the typo in testcase and added the override annotation. (though
haven't uploaded the patch yet.)
{quote}BTW try ant precommit. Hopefully it'll show you that you need to use
@Override
{quote}
I tried doing so but it gave me some error stating _Rat problems were found!_ .
I tried searching over the internet but couldn't find anything useful, did some
playing around build.xml but all was in waste.
Anyways, what I want to ask is when you said about callers of
getParameterNamesiterator(), did you mean callers in SolrParams class only or
all callers of that iterator function?
What I mean to say is there are some functions in SolrParam class which are
using getParameterNamesiterator() and we can modify those functions for Java 5
foreach or Java 8 stream style. Or there are some classes which are extending
the SolrParams like ModifiableSolrParams, MultiMapSolrParams etc which are
using getParameterNamesiterator() and we can modify those for Java 5 foreach or
Java 8 stream style. Though ModifiableSolrParams is just an example, I check
for this class and it is using getParameterNamesiterator() for its
add(SolrParams params) function which has never been called, so no point in
changing that, I guess.
was (Author: tvaishna):
{quote}The default impl can produce a Map.Entry with a getValue that calls
through to getParams.
{quote}
This I didn't think of. Thanks for pointing it out, have fixed now and will
upload with the latest patch.
I have fixed the typo in testcase and added the override annotation. (though
haven't uploaded the patch yet.)
{quote}BTW try ant precommit. Hopefully it'll show you that you need to use
@Override
{quote}
I tried doing so but it gave me some error stating _Rat problems were found!_ .
I tried searching over the internet but couldn't find anything useful, did some
playing around build.xml but all was in waste.
Anyways, what I want to ask is when you said about callers of
getParameterNamesiterator(), did you mean callers in SolrParams class only or
all callers of that iterator function?
I mean there are some functions in SolrParam class which are using
getParameterNamesiterator() and we can modify those functions for Java 5
foreach or Java 8 stream style. Or there are some classes which are extending
the SolrParams like ModifiableSolrParams, MultiMapSolrParams etc which are
using getParameterNamesiterator() and we can modify those for Java 5 foreach or
Java 8 stream style. Though ModifiableSolrParams is just an example, I check
for this class and it is using getParameterNamesiterator() for its
add(SolrParams params) function which has never been called, so no point in
changing that, I guess.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16411026#comment-16411026
]
Tapan Vaishnav commented on SOLR-11913:
---
{quote}The default impl can produce a Map.Entry with a getValue that calls
through to getParams.
{quote}
This I didn't think of. Thanks for pointing it out, have fixed now and will
upload with the latest patch.
I have fixed the typo in testcase and added the override annotation. (though
haven't uploaded the patch yet.)
{quote}BTW try ant precommit. Hopefully it'll show you that you need to use
@Override
{quote}
I tried doing so but it gave me some error stating _Rat problems were found!_ .
I tried searching over the internet but couldn't find anything useful, did some
playing around build.xml but all was in waste.
Anyways, what I want to ask is when you said about callers of
getParameterNamesiterator(), did you mean callers in SolrParams class only or
all callers of that iterator function?
I mean there are some functions in SolrParam class which are using
getParameterNamesiterator() and we can modify those functions for Java 5
foreach or Java 8 stream style. Or there are some classes which are extending
the SolrParams like ModifiableSolrParams, MultiMapSolrParams etc which are
using getParameterNamesiterator() and we can modify those for Java 5 foreach or
Java 8 stream style. Though ModifiableSolrParams is just an example, I check
for this class and it is using getParameterNamesiterator() for its
add(SolrParams params) function which has never been called, so no point in
changing that, I guess.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410663#comment-16410663
]
Tapan Vaishnav commented on SOLR-11913:
---
{quote}1. When uploading updated patches, please use an identical filename.
JIRA tracks revisions provided that the file name hasn't changed.
{quote}
I see.
{quote}Though you did provide a method getMapEntryIteretor which should be
renamed to iterator.
{quote}
Done.
Please have a look, apologies for making you review again n again.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tapan Vaishnav updated SOLR-11913:
--
Attachment: SOLR-11913.patch
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16407783#comment-16407783
]
Tapan Vaishnav commented on SOLR-11913:
---
[~dsmiley]
Thanks for your review.
I have fixed the pointed out changes and attached as SOLR-11913_v2.patch.
Please, have a look whenever you get time.
> The key part as referenced in the description – having SolrParams implement
>Iterable wasn't done.
I thought that we had to implement the function not as in the _implements_
keyword.
> Why did you create SolrParams.getMapEntry? You could inline it to do an
> anonymous inner class
It wasn't creating any unnecessary new object and I thought that we might use
it in future but has been fixed now.
> Please override this for ModifiableSolrParams to return a more optimal
> implementation.
I have overridden the _iterator()_ from Iterable class for
ModifiableSolrParams. But there are other classes too which extend SolrParams
and need to be modified. Will do after the next review.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tapan Vaishnav updated SOLR-11913:
--
Attachment: SOLR-11913_v2.patch
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16403273#comment-16403273
]
Tapan Vaishnav commented on SOLR-11913:
---
[~dsmiley] [~gus_heck]
I have added the patch. Please have a look at it and let me know your feedback.
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tapan Vaishnav updated SOLR-11913:
--
Attachment: SOLR-11913.patch
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
> Attachments: SOLR-11913.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tapan Vaishnav updated SOLR-11913:
--
Comment: was deleted
(was: [~dsmiley] Thanks for your quick reply.
I think this should work. Iterable can just produce the iterator which we can
iterate over to. And for the value of each [key: value] pair of _Map.Entry_ ,
we can use the _getParams_ internally by passing the _Map.Entry_ object(which
would be nothing but the _iterator.next_) into the _getValue_ function of
_ModifiableSolrParams_ class.
{noformat}
public Iterator> Iterable(){
Set set = vals.entrySet();
return set.iterator();
}
public String[] getValue(Map.Entry map){
if (map!=null) {
return getParams(map.getKey());
}
return null;
}
{noformat})
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375926#comment-16375926
]
Tapan Vaishnav commented on SOLR-11913:
---
[~dsmiley] Thanks for your quick reply.
I think this should work. Iterable can just produce the iterator which we can
iterate over to. And for the value of each [key: value] pair of _Map.Entry_ ,
we can use the _getParams_ internally by passing the _Map.Entry_ object(which
would be nothing but the _iterator.next_) into the _getValue_ function of
_ModifiableSolrParams_ class.
{noformat}
public Iterator> Iterable(){
Set set = vals.entrySet();
return set.iterator();
}
public String[] getValue(Map.Entry map){
if (map!=null) {
return getParams(map.getKey());
}
return null;
}
{noformat}
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable>
[
https://issues.apache.org/jira/browse/SOLR-11913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372535#comment-16372535
]
Tapan Vaishnav commented on SOLR-11913:
---
>From whatever I understood(Apologies if I'm heavily wrong, just started using
>Solr)
scratch。。。
{noformat}
public Iterator> Iterable(SolrParams params){
vals = new LinkedHashMap<>();
if( params != null ) {
this.add( params );
}
Iterator> entries = vals.entrySet().iterator();
return entries;
}
public String[] getValue(Iterator> it){
if (it.hasNext()) {
Map.Entry pair = it.next();
return getParams(pair.getKey());
}
return null;
}
{noformat}
> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Priority: Minor
> Labels: newdev
>
> SolrJ ought to implement {{Iterable>}} so that
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8
> streams. The implementation on ModifiableSolrParams can delegate through to
> the underlying LinkedHashMap entry set. The default impl can produce a
> Map.Entry with a getValue that calls through to getParams.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
