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
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
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
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"
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
[
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
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
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
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
[
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
[
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=12683032#action_12683032
]
Mark Miller commented on LUCENE-1522:
-
bq. Lucene H1. Too many elipses, and fragments
[
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-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1145:
--
Assignee: Michael McCandless
> DisjunctionSumScorer small tweak
>
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:comment-tabpanel&focusedCommentId=12683058#action_12683058
]
Michael McCandless commented on LUCENE-1145:
I plan to commit shortly.
> Disj
[
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
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
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:
[
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
> -
[
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-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-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-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-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-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1490.
Resolution: Fixed
Thanks Daniel!
> CJKTokenizer convert HALFWIDTH_AND_FULLWIDTH
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-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
[
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
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-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
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 updated LUCENE-652:
--
Attachment: LUCENE-652.patch
I added o.a.l.document.CompressionTools, with static metho
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-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 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-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1435:
--
Assignee: Michael McCandless
> CollationKeyFilter: convert tokens into Collati
[
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-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-1434:
--
Assignee: Michael McCandless
> IndexableBinaryStringTools: convert arbitrary b
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-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
[
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=12683174#action_12683174
]
Steven Rowe commented on LUCENE-1435:
-
It's in contrib/miscellaneous/
I used Analyzin
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-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1434.
Resolution: Fixed
Thanks Steven!
> IndexableBinaryStringTools: convert arbitrary
[
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
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
> >> 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
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
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
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
> > 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
[
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
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
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
[
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
[
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-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
59 matches
Mail list logo