[
https://issues.apache.org/jira/browse/LUCENE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-1435:
Attachment: LUCENE-1435.patch
New patch that compiles.
I'm not sure how this ever worked previous
[
https://issues.apache.org/jira/browse/LUCENE-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683313#action_12683313
]
Adriano Crestani commented on LUCENE-1567:
--
It's probably not ok, since lucene bu
[
https://issues.apache.org/jira/browse/LUCENE-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683308#action_12683308
]
Luis Alves commented on LUCENE-1567:
Should the Flexible Query Parser patch be committ
New flexible query parser
-
Key: LUCENE-1567
URL: https://issues.apache.org/jira/browse/LUCENE-1567
Project: Lucene - Java
Issue Type: New Feature
Components: QueryParser
Environment: N/A
Uwe Schindler wrote:
>> If so... maybe we could extend FieldCache's parser to allow it to
>> stop-early? Ie it'd get the TermEnum, iterate through all the full
>> precision terms first, asking your parser to convert to long/int,
>> and then when your parser sees the very first not-full-precision
[
https://issues.apache.org/jira/browse/LUCENE-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683240#action_12683240
]
Daniel Cheng commented on LUCENE-1490:
--
This was discovered by Chan
http://www.cnblo
> > Though, won't this make loading the field cache more costly since
> > you'll iterate through many more terms?
>
> Or... do the full precision fields always order above all lower
> precision fields across all docs?
The highest precision terms have a shift value of 0. As the first char of
the e
Michael McCandless wrote:
> Though, won't this make loading the field cache more costly since
> you'll iterate through many more terms?
Or... do the full precision fields always order above all lower
precision fields across all docs?
If so... maybe we could extend FieldCache's parser to allow i
Uwe Schindler wrote:
I have no problem with it! Thanks!
What I would like to be fixed before moving it to core is the fact
that a
additional helper field is needed for the trie values. If everything
could
be in one field and the field is still sortable, it would be fine.
For that,
the or
Uwe Schindler wrote:
I would be happy with a renaming to "NumberRangeFilter", but "trie"
should appear somewhere in the docs.
I like this approach (and referencing the original paper); I think
it's important the javadocs give enough detail about how it works so
that one can understand the bi
> >> I think we should move TrieRange* into core before 2.9?
> >>
> >> It's received alot of attention, from both developers (Uwe & Yonik did
> >> lots of iterations, and Solr is folding it in) and user interest.
> >>
> >> It's a simpler & more scalable way to index numeric fields that you
> >> int
Indeed! I'll fix on trunk.
Mike
Mark Miller wrote:
Just a note so I don't forget:
The file formats page says their are 4 files used for termvectors
but their is only 3 that I can see: tvx tvd tvf.
http://lucene.apache.org/java/2_4_1/fileformats.html
--
- Mark
http://www.lucidimaginati
[
https://issues.apache.org/jira/browse/LUCENE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683182#action_12683182
]
Michael McCandless commented on LUCENE-1435:
OK, thanks for the pointer -- I l
[
https://issues.apache.org/jira/browse/LUCENE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1434.
Resolution: Fixed
Thanks Steven!
> IndexableBinaryStringTools: convert arbitrary
Just a note so I don't forget:
The file formats page says their are 4 files used for termvectors but
their is only 3 that I can see: tvx tvd tvf.
http://lucene.apache.org/java/2_4_1/fileformats.html
--
- Mark
http://www.lucidimagination.com
---
[
https://issues.apache.org/jira/browse/LUCENE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683174#action_12683174
]
Steven Rowe commented on LUCENE-1435:
-
It's in contrib/miscellaneous/
I used Analyzin
[
https://issues.apache.org/jira/browse/LUCENE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683171#action_12683171
]
Michael McCandless commented on LUCENE-1434:
This looks good. I plan to commi
[
https://issues.apache.org/jira/browse/LUCENE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683167#action_12683167
]
Michael McCandless commented on LUCENE-1435:
Steven, I'm hitting compilation e
I have no problem with it! Thanks!
What I would like to be fixed before moving it to core is the fact that a
additional helper field is needed for the trie values. If everything could
be in one field and the field is still sortable, it would be fine. For that,
the order of terms in the FieldCache
[
https://issues.apache.org/jira/browse/LUCENE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1434:
--
Assignee: Michael McCandless
> IndexableBinaryStringTools: convert arbitrary b
[
https://issues.apache.org/jira/browse/LUCENE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683155#action_12683155
]
Michael McCandless commented on LUCENE-1435:
I think we should commit this to
[
https://issues.apache.org/jira/browse/LUCENE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1435:
--
Assignee: Michael McCandless
> CollationKeyFilter: convert tokens into Collati
On Wed, Mar 18, 2009 at 23:08, Andi Vajda wrote:
>
> On Mar 18, 2009, at 13:01, Michael McCandless
> wrote:
>
>> I think we should move TrieRange* into core before 2.9?
>>
>> It's received alot of attention, from both developers (Uwe & Yonik did
>> lots of iterations, and Solr is folding it in) a
[
https://issues.apache.org/jira/browse/LUCENE-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683149#action_12683149
]
Michael McCandless commented on LUCENE-1496:
If we move trie/* into core, what
On Mar 18, 2009, at 13:01, Michael McCandless
wrote:
I think we should move TrieRange* into core before 2.9?
It's received alot of attention, from both developers (Uwe & Yonik did
lots of iterations, and Solr is folding it in) and user interest.
It's a simpler & more scalable way to index
[
https://issues.apache.org/jira/browse/LUCENE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-652:
--
Attachment: LUCENE-652.patch
I added o.a.l.document.CompressionTools, with static metho
I think we should move TrieRange* into core before 2.9?
It's received alot of attention, from both developers (Uwe & Yonik did
lots of iterations, and Solr is folding it in) and user interest.
It's a simpler & more scalable way to index numeric fields that you
intend to sort and/or do range quer
[
https://issues.apache.org/jira/browse/LUCENE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-652:
-
Assignee: Michael McCandless
> Compressed fields should be "externalized" (from F
On Mar 18, 2009, at 12:04 PM, Zaid Md. Abdul Wahab Sheikh wrote:
Hi lucene,
In this link http://wiki.apache.org/general/SummerOfCode2009 , there
are no project ideas for Lucene proper. (Only ideas for Mahout
listed).
This requires someone (has to be a committer) willing to mentor. I'd
[
https://issues.apache.org/jira/browse/LUCENE-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1533:
---
Fix Version/s: (was: 2.9)
Clearing fix version.
> Deleted documents as a Filter
[
https://issues.apache.org/jira/browse/LUCENE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1526:
---
Fix Version/s: (was: 2.9)
I don't think we should block 2.9 for this.
> Tombsto
On Mar 18, 2009, at 7:57 AM, Michael McCandless wrote:
Coming from the discussions in LUCENE-1522 (improving highlighter), I
think at some point we should merge Span*Query into their normal
counterparts, if possible.
Ie, there should be only one TermQuery that can do both what the
current Ter
[
https://issues.apache.org/jira/browse/LUCENE-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1490.
Resolution: Fixed
Thanks Daniel!
> CJKTokenizer convert HALFWIDTH_AND_FULLWIDTH
[
https://issues.apache.org/jira/browse/LUCENE-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1490:
--
Assignee: Michael McCandless
> CJKTokenizer convert HALFWIDTH_AND_FULLWIDTH_
[
https://issues.apache.org/jira/browse/LUCENE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1561:
--
Assignee: Michael McCandless
> Maybe rename Field.omitTf, and strengthen the j
[
https://issues.apache.org/jira/browse/LUCENE-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1561:
---
Attachment: LUCENE-1561.patch
Attached patch. I renamed to "omitTermFreqAndPosition
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683079#action_12683079
]
David Kaelbling commented on LUCENE-1522:
-
Hi,
Our application wants to find and
[
https://issues.apache.org/jira/browse/LUCENE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1472:
---
Fix Version/s: (was: 2.9)
Removing 2.9 target.
> DateTools.stringToDate() can c
[
https://issues.apache.org/jira/browse/LUCENE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1145.
Resolution: Fixed
Thanks Eks and Paul!
> DisjunctionSumScorer small tweak
> -
I think creating a better Highlighter for Lucene, which is actively
being discussed:
https://issues.apache.org/jira/browse/LUCENE-1522
would make a good GSoC project, but I don't think I have time to mentor.
Realtime search is currently in progress already, being tracked/iterated
here:
Hi Z.S.,
I'll update LUCENE-1313 after LUCENE-1516 is committed. I can post the
basic new patch I have for LUCENE-1313 (heavily simplified compared to the
previous patches), however it will assume LUCENE-1516. The other area that
will need to be addressed is standard benchmarking for different r
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683064#action_12683064
]
Marvin Humphrey commented on LUCENE-1522:
-
> OK, it sounds like one can simply use
[
https://issues.apache.org/jira/browse/LUCENE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683058#action_12683058
]
Michael McCandless commented on LUCENE-1145:
I plan to commit shortly.
> Disj
Hi lucene,
In this link http://wiki.apache.org/general/SummerOfCode2009 , there are no
project ideas for Lucene proper. (Only ideas for Mahout listed). Please put
up some ideas for Lucene there or please mention some popular open issues
that might be suitable as a GSoC project.
I would very much li
[
https://issues.apache.org/jira/browse/LUCENE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1145:
--
Assignee: Michael McCandless
> DisjunctionSumScorer small tweak
>
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683053#action_12683053
]
Michael McCandless commented on LUCENE-1522:
{quote}
Something like that. An
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683032#action_12683032
]
Mark Miller commented on LUCENE-1522:
-
bq. Lucene H1. Too many elipses, and fragments
[
https://issues.apache.org/jira/browse/LUCENE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-1550:
---
Assignee: Grant Ingersoll
> Add N-Gram String Matching for Spell Checking
>
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683030#action_12683030
]
Marvin Humphrey commented on LUCENE-1522:
-
> I think we may need a tree-structured
On Wed, Mar 18, 2009 at 1:32 PM, Mark Miller wrote:
>>> In some usecases this could be important especially where the power of
>>> a span query is not required.
>
> I think the power of a spanquery is required for payloads though - the term
> query will not hit each position to do payload loading
In some usecases this could be important especially where the power of
a span query is not required.
I think the power of a spanquery is required for payloads though - the term
query will not hit each position to do payload loading - there is no need for
termquery to enumerate positions. Right
Coming from the discussions in LUCENE-1522 (improving highlighter), I
think at some point we should merge Span*Query into their normal
counterparts, if possible.
Ie, there should be only one TermQuery that can do both what the
current TermQuery does, and also what SpanTermQuery does. It's able
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682987#action_12682987
]
Michael McCandless commented on LUCENE-1522:
OK to sum up here with observati
[
https://issues.apache.org/jira/browse/LUCENE-1522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682985#action_12682985
]
Michael McCandless commented on LUCENE-1522:
{quote}
>> ANDQuery, ORQuery, an
See https://issues.apache.org/jira/browse/LUCENE-1017 for some
background. Have you measured BTQ versus the SpanTermQuery? Position
based stuff is often slower.
SpanQueries could use some performance assessments, that is for sure.
Ideally, I think you should compare:
TermQuery v. SpanTQ
Also, rollback is still possible after a commit as long as you're using
a deletion policy that keeps more than one commit around, by
opening the IndexWriter on a prior commit point.
Mike
Nadav Har'El wrote:
On Mon, Feb 23, 2009, Jason Rutherglen wrote about "Re:
IndexWriter.rollback() logic"
Nadav Har'El wrote:
On Mon, Feb 23, 2009, Jason Rutherglen wrote about "Re:
IndexWriter.rollback() logic":
Howdy An,
Commit means the changes are committed, there's no rollback at that
point.
Also in the futuer please post your questions to java-dev@lucene.apache.org
Actually, An does
Nothing different, I'm just concerned about the performance as the
SpanQuerys take about twice as long as a term query.
I run a little benchmark and found BoostingTermQuery being 1.5 times
slower than TermQuery without any payloads in the index.
In some usecases this could be important especially w
On Mon, Feb 23, 2009, Jason Rutherglen wrote about "Re: IndexWriter.rollback()
logic":
> Howdy An,
>
> Commit means the changes are committed, there's no rollback at that point.
>
> Also in the futuer please post your questions to java-dev@lucene.apache.org
Actually, An does make a good point t
59 matches
Mail list logo
