[ https://issues.apache.org/jira/browse/LUCENE-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13974982#comment-13974982 ]
Robert Muir commented on LUCENE-5620: ------------------------------------- {quote} It makes me wonder whether length normalization shouldn't use max position instead of term count when it is available. {quote} This is your choice, its whatever your similarity uses. currently most of the similarities shipped with lucene have an option you can choose. The problem is if you are synonyms-heavy, its bad. But I opened and issue and changed the default to exactly this way in lucene 3.1 because so many users were injecting 'fake' terms without thinking about the consequences. {quote} The drawbacks of the field splitting were 1) QParser flexibility- (not being forced to use a dismax defType in order to query multiple fields in a single query. 2) "readability" - the developer / user could see in a single place all the terms a query could match in an indexed document via the admin UI without asking him to understand a parsedQuery string or the qf param. 3) term position - enabling a phrase query that would match "originalTerm stemmedTerm". Enabling it in a splitted field would mean saving the original term (dictionary and posting) twice, 3) perf (more of an anecdote) - as the terms were generally suffix stemmed we had good chances of loading the same term block and posting list to memory as they should be sequential. {quote} Those all sound like solr problems: not relevant to any decisions to be made here. In lucene (even the queryparser) you can override phrase queries, to use unstemmed field for example. And if you want to do it that way, just enable documents and frequencies on the stemmed field (no proximity necessary there, just ordinary scoring). > LowerCaseFilter.preserveOriginal > -------------------------------- > > Key: LUCENE-5620 > URL: https://issues.apache.org/jira/browse/LUCENE-5620 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Mike Sokolov > Attachments: LUCENE-5620.patch > > > Following closely the model of LUCENE-5437 (which worked on > ASCIIFoldingFilter), this patch adds the ability to preserve the original > token to LowerCaseFilter. This is useful if you want an all-lowercase search > term to match without regard to case, while search terms with uppercase > letters match in a case-sensitive manner. -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org