regardless of it, I really do not understand the call to initTermBuffer() in
termLength()? What is it good for?
this method will return the same value in both cases, zero, I see no harm in
removing it?
/** Return number of valid characters (length of the term)
* in the termBuffer array
[
https://issues.apache.org/jira/browse/LUCENE-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eks Dev updated LUCENE-1616:
Attachment: LUCENE-1616.patch
> add one setter for start and end offset to OffsetAttribute
> -
add one setter for start and end offset to OffsetAttribute
--
Key: LUCENE-1616
URL: https://issues.apache.org/jira/browse/LUCENE-1616
Project: Lucene - Java
Issue Type: Improvement
thanks Uwe,
looks like nice use case to cover, but I was/am not sure what would be the way
around it?
Your propsal sounds OK to me, but I am not familiar enough with this API to say
for sure...
I guess we would need to make this put safer to prevent people making silly
mistakes defining cla
There is one problem: if you extend TermAttribute, the class is different
(which is the key in the attributes list). So when you initialize the
TokenStream and do a
YourClass termAtt = (YourClass) addAttribute(YourClass.class)
...you create a new attribute. So one possibility would be to also spe
I am just looking into new TermAttribute usage and wonder what would be the
best way to implement PrefixFilter that would filter out some Terms that have
some prefix,
something like this, where '-' represents my prefix:
public final boolean incrementToken() throws IOException {
// the f
[
https://issues.apache.org/jira/browse/LUCENE-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1594:
---
Attachment: LUCENE-1594.patch
Another iteration... this patch is very large because
This is great feedback on the new Collector API, Uwe. Thanks!
It's awesome that you no longer have to warm your searchers... but be
careful when a large segment merge commits.
Did you hit any snags/problems/etc. that we should fix before releasing 2.9?
Mike
On Sun, Apr 26, 2009 at 9:54 AM, Uwe
[
https://issues.apache.org/jira/browse/LUCENE-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702901#action_12702901
]
Eks Dev commented on LUCENE-1615:
-
sure, replacing Fieldable is good, just noticed quick
[
https://issues.apache.org/jira/browse/LUCENE-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702896#action_12702896
]
Uwe Schindler commented on LUCENE-1615:
---
We know this problem, your fix seems ok (LU
[
https://issues.apache.org/jira/browse/LUCENE-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eks Dev updated LUCENE-1615:
Attachment: LUCENE-1615.patch
> deprecated method used in fieldsReader / setOmitTf()
> ---
deprecated method used in fieldsReader / setOmitTf()
Key: LUCENE-1615
URL: https://issues.apache.org/jira/browse/LUCENE-1615
Project: Lucene - Java
Issue Type: Improvement
Compon
Some status update:
> > George, did you mean LUCENE-1516 below? (LUCENE-1313 is a further
> > improvement to near real-time search that's still being iterated on).
> >
> > In general I would say 2.9 seems to be in rather active development
> still
> > ;)
> >
> > I too would love to hear about pro
13 matches
Mail list logo
