[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742514#action_12742514 ] Michael McCandless commented on LUCENE-1748: Patch looks good... just need to fix back-compat tests. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9 > > Attachments: LUCENE-1748.patch, LUCENE-1748.patch, LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742270#action_12742270 ] Michael McCandless commented on LUCENE-1748: bq. I'm tempted to make Spans abstract. +1 > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9 > > Attachments: LUCENE-1748.patch, LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742104#action_12742104 ] Mark Miller commented on LUCENE-1748: - I'm tempted to make Spans abstract. We don't get these chances often. We managed to make Weight abstract for 2.9, and I think similar logic applies here. We are already breaking the interface - why not go abstract as well? Its a little more trouble, but we are already so far up the creak, it could be worth it no? Its very hard to get rid of these interfaces in a normal situation, and a better opportunity may not present itself. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9 > > Attachments: LUCENE-1748.patch, LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739104#action_12739104 ] Mark Miller commented on LUCENE-1748: - Thanks Hugh! > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9 > > Attachments: LUCENE-1748.patch, LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739017#action_12739017 ] Mark Miller commented on LUCENE-1748: - Okay - my first time messing with the back compat tests, and changing the src felt dirty - but nothing else that can be done, and as you say, it doesn't hurt anything. Ive got things worked out locally. I'll give a shot at commiting this later today. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9, 3.0, 3.1 > > Attachments: LUCENE-1748.patch, LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738921#action_12738921 ] Michael McCandless commented on LUCENE-1748: Can you make the corresponding changes to the backcompat branch's sources & tests? Note that they only need to be "stubs", so that things compile, since it's the trunk's JAR that they'll be tested against. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9, 3.0, 3.1 > > Attachments: LUCENE-1748.patch, LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738714#action_12738714 ] Mark Miller commented on LUCENE-1748: - Has something like this come up in the past? How was the back compat branch handled? Should I just remove the PayloadSpans test? It doesn't seem right to apply the patch to the back compat src - it wouldn't apply cleanly anyway, and it doesn't seem right to fit it in. I guess it may not matter though? I'm just worried it will be like pulling a string ... the issue: The PayloadSpans test was made to test PayloadSpans - but that class shouldn't have been made and the methods from it have been added to Spans, and its been removed. Now the back compat branch test won't compile against the back compat src. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9, 3.0, 3.1 > > Attachments: LUCENE-1748.patch, LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738183#action_12738183 ] Mark Miller commented on LUCENE-1748: - I'm going to commit this to the backcompat branch as well - I can't just change the tests - the src has to be changed as well because the tests compile against it rather than trunk. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9, 3.0, 3.1 > > Attachments: LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12736674#action_12736674 ] Mark Miller commented on LUCENE-1748: - This is going to require a patch to the 2.4 back compat branch to pass tests. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless >Assignee: Mark Miller > Fix For: 2.9, 3.0, 3.1 > > Attachments: LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735113#action_12735113 ] Hugh Cayless commented on LUCENE-1748: -- Just wanted to say thanks for your responsiveness on this. It really validates my faith in Lucene as a project. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.9, 3.0, 3.1 > > Attachments: LUCENE-1748.patch > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732938#action_12732938 ] Earwin Burrfoot commented on LUCENE-1748: - bq. We should drop PayloadSpans and just add getPayload to Spans. This should be a compile time break. +1 > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.9, 3.0, 3.1 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732601#action_12732601 ] Mark Miller commented on LUCENE-1748: - Something should be done here. I admit I havn't spent a lot of time thinking yet, but off the cuff : 1. We should drop PayloadSpans and just add getPayload to Spans. This should be a compile time break. 2. We need a way to *not* collect payloads. Now they will be collected if they are there whether they are used or not. Perhaps an argument in the SpanQuery constructor? It can't really be getSpans because the user would need to control it. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.9, 3.0, 3.1 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731979#action_12731979 ] Mark Miller commented on LUCENE-1748: - Okay, so it says: Implementing classes that want access to the payloads will need to implement this. But in reality, if you don't implement it, looks like your screwed if you add it to the container SpanQueries. whether you access the payloads or not. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.4.2 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731984#action_12731984 ] Mark Miller commented on LUCENE-1748: - bq. the whole getPayloadSpans deal is a herecy. heh. don't dig too deep - it also has to load all of the payloads as it matches whether you ask for them or not (if they exist). The ordered or unordered matcher also has to load them and dump them in certain situation when they are not actually needed. Lets look at what we need to do to fix this - we don't have to worry too much about back compat, cause its already pretty screwed I think. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.4.2 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731971#action_12731971 ] Mark Miller commented on LUCENE-1748: - bq. From my perspective at least, backwards compatibility is already broken, since Lucene doesn't work with SpanQuerys that don't implement getPayloadSpans Ah, I see - I hadn't looked at this issue in a long time. It looks like you must implement it to do much of anything right? We need to address this better - perhaps abstract is the way to go. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.4.2 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[
https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731972#action_12731972
]
Earwin Burrfoot commented on LUCENE-1748:
-
I took a glance at the code, the whole getPayloadSpans deal is a herecy.
Each and every implementation looks like:
public PayloadSpans getPayloadSpans(IndexReader reader) throws IOException {
return (PayloadSpans) getSpans(reader);
}
Moving it to the base SpanQuery is broken equally to current solution, but
yields much less strange copypaste.
I also have a faint feeling that if you expose a method like
ClassA method();
you can then upgrade it to
SubclassOfClassA method();
without breaking drop-in compatibility, which renders getPayloadSpans vs
getSpans alternative totally useless
> getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
> --
>
> Key: LUCENE-1748
> URL: https://issues.apache.org/jira/browse/LUCENE-1748
> Project: Lucene - Java
> Issue Type: Bug
> Components: Query/Scoring
>Affects Versions: 2.4, 2.4.1
> Environment: all
>Reporter: Hugh Cayless
> Fix For: 2.4.2
>
>
> I just spent a long time tracking down a bug resulting from upgrading to
> Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was
> written against 2.3. Since the project's SpanQuerys didn't implement
> getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans
> which returned null and caused a NullPointerException in the Lucene code, far
> away from the actual source of the problem.
> It would be much better for this kind of thing to show up at compile time, I
> think.
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731968#action_12731968 ] Mark Miller commented on LUCENE-1748: - My response sent to mailing list: >>bq. Shouldnt it throw a runtime exception (unsupported operation?) or >>something? >>What is the difference between adding an abstract method and adding a method >>that throws exception in regards to jar drop in back compat? >>In both cases when you drop your new jar in you get an exception, except in >>the latter case exception is deferred. Yeah, its dicey - I suppose the idea is that, if you used the code as you used to, it wouldnt try and call getPayloadSpans? And so if you kept using non payloadspans functionality, you would be set, and if you tried to use payloadspans you would get an exception saying the class needed to be updated? But if you make it abstract, we lose jar drop (I know I've read we don't have it for this release anyway) in and everyone has to implement the method. At least with the exception, if you are using the class as you used to, you can continue to do so with no work? Not that I 've considered it for very long at the moment. I know, I see your point - this back compat stuff is always dicey - thats why I throw it out there with a question mark - hopefully others will continue to chime in. - Show quoted text - > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.4.2 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: [jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
>>bq. Shouldnt it throw a runtime exception (unsupported operation?) or something? >>What is the difference between adding an abstract method and adding a method that throws exception in regards to jar drop in back compat? >>In both cases when you drop your new jar in you get an exception, except in the latter case exception is deferred. Yeah, its dicey - I suppose the idea is that, if you used the code as you used to, it wouldnt try and call getPayloadSpans? And so if you kept using non payloadspans functionality, you would be set, and if you tried to use payloadspans you would get an exception saying the class needed to be updated? But if you make it abstract, we lose jar drop (I know I've read we don't have it for this release anyway) in and everyone has to implement the method. At least with the exception, if you are using the class as you used to, you can continue to do so with no work? Not that I 've considered it for very long at the moment. I know, I see your point - this back compat stuff is always dicey - thats why I throw it out there with a question mark - hopefully others will continue to chime in. On Thu, Jul 16, 2009 at 9:38 AM, Earwin Burrfoot (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731939#action_12731939] > > Earwin Burrfoot commented on LUCENE-1748: > - > > bq. Shouldnt it throw a runtime exception (unsupported operation?) or > something? > What is the difference between adding an abstract method and adding a > method that throws exception in regards to jar drop in back compat? > In both cases when you drop your new jar in you get an exception, except in > the latter case exception is deferred. > > > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be > abstract > > > -- > > > > Key: LUCENE-1748 > > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > > Project: Lucene - Java > > Issue Type: Bug > > Components: Query/Scoring > >Affects Versions: 2.4, 2.4.1 > > Environment: all > >Reporter: Hugh Cayless > > Fix For: 2.4.2 > > > > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, > far away from the actual source of the problem. > > It would be much better for this kind of thing to show up at compile > time, I think. > > Thanks! > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- -- - Mark http://www.lucidimagination.com
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731940#action_12731940 ] Hugh Cayless commented on LUCENE-1748: -- Ah. I figured it would be something like that. Yes, if abstract isn't possible, an UnsupportedOperationException would at least get closer to the source of the problem. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.4.2 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731939#action_12731939 ] Earwin Burrfoot commented on LUCENE-1748: - bq. Shouldnt it throw a runtime exception (unsupported operation?) or something? What is the difference between adding an abstract method and adding a method that throws exception in regards to jar drop in back compat? In both cases when you drop your new jar in you get an exception, except in the latter case exception is deferred. > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.4.2 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1748) getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract
[ https://issues.apache.org/jira/browse/LUCENE-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731935#action_12731935 ] Mark Miller commented on LUCENE-1748: - The reason it has a default impl is so that it won't break jar drop in back compat - if it was abstract, it would violate our back compat requirements. But you make a most excellent point. Shouldnt it throw a runtime exception (unsupported operation?) or something? > getPayloadSpans on org.apache.lucene.search.spans.SpanQuery should be abstract > -- > > Key: LUCENE-1748 > URL: https://issues.apache.org/jira/browse/LUCENE-1748 > Project: Lucene - Java > Issue Type: Bug > Components: Query/Scoring >Affects Versions: 2.4, 2.4.1 > Environment: all >Reporter: Hugh Cayless > Fix For: 2.4.2 > > > I just spent a long time tracking down a bug resulting from upgrading to > Lucene 2.4.1 on a project that implements some SpanQuerys of its own and was > written against 2.3. Since the project's SpanQuerys didn't implement > getPayloadSpans, the call to that method went to SpanQuery.getPayloadSpans > which returned null and caused a NullPointerException in the Lucene code, far > away from the actual source of the problem. > It would be much better for this kind of thing to show up at compile time, I > think. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
