[jira] [Commented] (SOLR-3200) When using SignatureUpdateProcessor with all fields configuration, it will assume only the fields present on the very first document only, ignoring any optional fields

2012-04-03 Thread Spyros Kapnissis (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245044#comment-13245044
 ] 

Spyros Kapnissis commented on SOLR-3200:


You're welcome:) 

Another thing that is not so intuitive here is when using the all fields 
configuration on a schema that has a unique key defined. This makes the whole 
process redundant as deduplication is already covered by the schema's unique 
key. 

So maybe it would be safe to assume that this configuration always means all 
fields - excluding the unique key by adding a runtime check to exclude this 
field from the signature calculation?

 When using SignatureUpdateProcessor with all fields configuration, it will 
 assume only the fields present on the very first document only, ignoring any 
 optional fields in subsequent documents in the signature generation.
 --

 Key: SOLR-3200
 URL: https://issues.apache.org/jira/browse/SOLR-3200
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 1.4, 3.1, 3.2, 3.3, 3.4, 3.5, 4.0
Reporter: Spyros Kapnissis
Assignee: Hoss Man
 Fix For: 3.6, 4.0

 Attachments: SOLR-3200.patch


 This can result in non-duplicate documents being left out of the index. A 
 solution would be that the fields to be used in the signature generation are 
 recalculated with every document inserted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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



[jira] [Commented] (LUCENE-3508) Decompounders based on CompoundWordTokenFilterBase cannot be used with custom attributes

2011-10-25 Thread Spyros Kapnissis (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/LUCENE-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13135103#comment-13135103
 ] 

Spyros Kapnissis commented on LUCENE-3508:
--

Looks great now, thanks a lot guys!

 Decompounders based on CompoundWordTokenFilterBase cannot be used with custom 
 attributes
 

 Key: LUCENE-3508
 URL: https://issues.apache.org/jira/browse/LUCENE-3508
 Project: Lucene - Java
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 3.4, 4.0
Reporter: Spyros Kapnissis
Assignee: Uwe Schindler
 Fix For: 3.5, 4.0

 Attachments: LUCENE-3508.patch, LUCENE-3508.patch, LUCENE-3508.patch, 
 LUCENE-3508.patch, LUCENE-3508.patch


 The CompoundWordTokenFilterBase.setToken method will call clearAttributes() 
 and then will reset only the default Token attributes (term, position, flags, 
 etc) resulting in any custom attributes losing their value. Commenting out 
 clearAttributes() seems to do the trick, but will fail the 
 TestCompoundWordTokenFilter tests..

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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