You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2011/07/22 22:31:58 UTC
[jira] [Created] (SOLR-2669) SchemaField.calcProps has some
backwards validation
SchemaField.calcProps has some backwards validation
---------------------------------------------------
Key: SOLR-2669
URL: https://issues.apache.org/jira/browse/SOLR-2669
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Fix For: 3.4, 4.0
LUCENE-2048 drew my attention to SchemaField.calProps and made me realize that some of the validation checks in this method are backwards
The check rmuir added in LUCENE-2048 seems to just bea straight up mistake...
* {{omitTermFreqAndPosition=false, omitPositions=true}} ... ERROR
* {{omitTermFreqAndPosition=true, omitPositions=false}} ... NO error but non-sense
The following however are long standing oddities...
* {{indexed=false omitNorms=true}} ... ERROR
* {{indexed=false omitTermFreqAndPositions=true}} ... ERROR
* {{indexed=false omitNorms=false}} ... NO error but non-sense
* {{indexed=false omitTermFreqAndPositions=false}} ... NO error but non-sense
* (omitPositions was added to the "INDEX" check and has similar problems)
I asked yonik about this in IRC, and he speculates that the reason this test started out that way is that it doesn't make any sense to ask for some index specific stuff to be omited if you have already said you don't want indexing at all.
my counter point was that it doesn't *hurt* to ask for some indexing metadata to be omited, but it certainly doesn't make sense to explicitly ask for any of that metadata to be left in if you asid you don't want any indexing.
To draw an analogy: "Please omit the dressing from my salad, and please don't bring me a salad" is a redundant request, but it doesn't hurt anything. "Please make sure there is dressing on my salad, and please don't bring me a salad" makes no sense at all -- if you don't want the salad, then why are asking for dressing on it?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Updated] (SOLR-2669) SchemaField.calcProps has some
backwards validation
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-2669:
---------------------------
Attachment: SOLR-2669.patch
patch that reverses these validation checks, with test config additions demonstrating the combinations that should work, and BadIndexSchemaTest additions that demonstrate the combinations that *should* fail.
> SchemaField.calcProps has some backwards validation
> ---------------------------------------------------
>
> Key: SOLR-2669
> URL: https://issues.apache.org/jira/browse/SOLR-2669
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2669.patch
>
>
> LUCENE-2048 drew my attention to SchemaField.calProps and made me realize that some of the validation checks in this method are backwards
> The check rmuir added in LUCENE-2048 seems to just bea straight up mistake...
> * {{omitTermFreqAndPosition=false, omitPositions=true}} ... ERROR
> * {{omitTermFreqAndPosition=true, omitPositions=false}} ... NO error but non-sense
> The following however are long standing oddities...
> * {{indexed=false omitNorms=true}} ... ERROR
> * {{indexed=false omitTermFreqAndPositions=true}} ... ERROR
> * {{indexed=false omitNorms=false}} ... NO error but non-sense
> * {{indexed=false omitTermFreqAndPositions=false}} ... NO error but non-sense
> * (omitPositions was added to the "INDEX" check and has similar problems)
> I asked yonik about this in IRC, and he speculates that the reason this test started out that way is that it doesn't make any sense to ask for some index specific stuff to be omited if you have already said you don't want indexing at all.
> my counter point was that it doesn't *hurt* to ask for some indexing metadata to be omited, but it certainly doesn't make sense to explicitly ask for any of that metadata to be left in if you asid you don't want any indexing.
> To draw an analogy: "Please omit the dressing from my salad, and please don't bring me a salad" is a redundant request, but it doesn't hurt anything. "Please make sure there is dressing on my salad, and please don't bring me a salad" makes no sense at all -- if you don't want the salad, then why are asking for dressing on it?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Resolved] (SOLR-2669) SchemaField.calcProps has some
backwards validation
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man resolved SOLR-2669.
----------------------------
Resolution: Fixed
Assignee: Hoss Man
Committed revision 1150510. - 3x
> SchemaField.calcProps has some backwards validation
> ---------------------------------------------------
>
> Key: SOLR-2669
> URL: https://issues.apache.org/jira/browse/SOLR-2669
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2669.patch
>
>
> LUCENE-2048 drew my attention to SchemaField.calProps and made me realize that some of the validation checks in this method are backwards
> The check rmuir added in LUCENE-2048 seems to just bea straight up mistake...
> * {{omitTermFreqAndPosition=false, omitPositions=true}} ... ERROR
> * {{omitTermFreqAndPosition=true, omitPositions=false}} ... NO error but non-sense
> The following however are long standing oddities...
> * {{indexed=false omitNorms=true}} ... ERROR
> * {{indexed=false omitTermFreqAndPositions=true}} ... ERROR
> * {{indexed=false omitNorms=false}} ... NO error but non-sense
> * {{indexed=false omitTermFreqAndPositions=false}} ... NO error but non-sense
> * (omitPositions was added to the "INDEX" check and has similar problems)
> I asked yonik about this in IRC, and he speculates that the reason this test started out that way is that it doesn't make any sense to ask for some index specific stuff to be omited if you have already said you don't want indexing at all.
> my counter point was that it doesn't *hurt* to ask for some indexing metadata to be omited, but it certainly doesn't make sense to explicitly ask for any of that metadata to be left in if you asid you don't want any indexing.
> To draw an analogy: "Please omit the dressing from my salad, and please don't bring me a salad" is a redundant request, but it doesn't hurt anything. "Please make sure there is dressing on my salad, and please don't bring me a salad" makes no sense at all -- if you don't want the salad, then why are asking for dressing on it?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-2669) SchemaField.calcProps has some
backwards validation
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070241#comment-13070241 ]
Hoss Man commented on SOLR-2669:
--------------------------------
Thanks for the review rmuir
Committed revision 1150478. - trunk
Still working on backporting to 3x, i thought it was going to be straight forward but BadIndexSchemaTest is vastly diff on that branch because of SOLR-1846
(Poking around with this also made me realize that none of the validation Solr does accounts for inconsistencies between the fieldtype and the field, so i've spun that off into SOLR-2674)
> SchemaField.calcProps has some backwards validation
> ---------------------------------------------------
>
> Key: SOLR-2669
> URL: https://issues.apache.org/jira/browse/SOLR-2669
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2669.patch
>
>
> LUCENE-2048 drew my attention to SchemaField.calProps and made me realize that some of the validation checks in this method are backwards
> The check rmuir added in LUCENE-2048 seems to just bea straight up mistake...
> * {{omitTermFreqAndPosition=false, omitPositions=true}} ... ERROR
> * {{omitTermFreqAndPosition=true, omitPositions=false}} ... NO error but non-sense
> The following however are long standing oddities...
> * {{indexed=false omitNorms=true}} ... ERROR
> * {{indexed=false omitTermFreqAndPositions=true}} ... ERROR
> * {{indexed=false omitNorms=false}} ... NO error but non-sense
> * {{indexed=false omitTermFreqAndPositions=false}} ... NO error but non-sense
> * (omitPositions was added to the "INDEX" check and has similar problems)
> I asked yonik about this in IRC, and he speculates that the reason this test started out that way is that it doesn't make any sense to ask for some index specific stuff to be omited if you have already said you don't want indexing at all.
> my counter point was that it doesn't *hurt* to ask for some indexing metadata to be omited, but it certainly doesn't make sense to explicitly ask for any of that metadata to be left in if you asid you don't want any indexing.
> To draw an analogy: "Please omit the dressing from my salad, and please don't bring me a salad" is a redundant request, but it doesn't hurt anything. "Please make sure there is dressing on my salad, and please don't bring me a salad" makes no sense at all -- if you don't want the salad, then why are asking for dressing on it?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[jira] [Commented] (SOLR-2669) SchemaField.calcProps has some
backwards validation
Posted by "Robert Muir (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069919#comment-13069919 ]
Robert Muir commented on SOLR-2669:
-----------------------------------
{quote}
To draw an analogy: "Please omit the dressing from my salad, and please don't bring me a salad" is a redundant request, but it doesn't hurt anything. "Please make sure there is dressing on my salad, and please don't bring me a salad" makes no sense at all – if you don't want the salad, then why are asking for dressing on it?
{quote}
I think this logic makes sense... the whole intention for the positions checks was to throw an error in the nonsense case (I tested, doesn't actually work at all in trunk right now)
patch looks good, this stuff needed tests.
> SchemaField.calcProps has some backwards validation
> ---------------------------------------------------
>
> Key: SOLR-2669
> URL: https://issues.apache.org/jira/browse/SOLR-2669
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2669.patch
>
>
> LUCENE-2048 drew my attention to SchemaField.calProps and made me realize that some of the validation checks in this method are backwards
> The check rmuir added in LUCENE-2048 seems to just bea straight up mistake...
> * {{omitTermFreqAndPosition=false, omitPositions=true}} ... ERROR
> * {{omitTermFreqAndPosition=true, omitPositions=false}} ... NO error but non-sense
> The following however are long standing oddities...
> * {{indexed=false omitNorms=true}} ... ERROR
> * {{indexed=false omitTermFreqAndPositions=true}} ... ERROR
> * {{indexed=false omitNorms=false}} ... NO error but non-sense
> * {{indexed=false omitTermFreqAndPositions=false}} ... NO error but non-sense
> * (omitPositions was added to the "INDEX" check and has similar problems)
> I asked yonik about this in IRC, and he speculates that the reason this test started out that way is that it doesn't make any sense to ask for some index specific stuff to be omited if you have already said you don't want indexing at all.
> my counter point was that it doesn't *hurt* to ask for some indexing metadata to be omited, but it certainly doesn't make sense to explicitly ask for any of that metadata to be left in if you asid you don't want any indexing.
> To draw an analogy: "Please omit the dressing from my salad, and please don't bring me a salad" is a redundant request, but it doesn't hurt anything. "Please make sure there is dressing on my salad, and please don't bring me a salad" makes no sense at all -- if you don't want the salad, then why are asking for dressing on it?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org