Chris Hostetter wrote:
i haven't read the patch, but based on the jira description i don't think
this is attempting to reuse cached info across updates -- i think it's
just trying to address the issue of eliminating redundent TermEnum/TermDoc
iterating for similar ranges.
Correct. I have conve
[
https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472610
]
Michael McCandless commented on LUCENE-565:
---
OK, got it. I will change those 3 to package protection and t
[
https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-565.
---
Resolution: Fixed
> Supporting deleteDocuments in IndexWriter (Code and Performance R
Hey Doron,
I did add the dependency for the demo into the build. I suppose,
ideally, the benchmark build would force a build of the top level src
and demo. If you want to submit a patch for that, I can apply it.
-Grant
On Feb 13, 2007, at 12:51 AM, Doron Cohen wrote:
Hi,
Recent chan
[
https://issues.apache.org/jira/browse/LUCENE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-799.
Resolution: Fixed
Lucene Fields: [New, Patch Available] (was: [Patch Available, New]
OK, now that LUCENE-565 is also done, I think we can finally get the
2.1 release process going?
Mike
Grant Ingersoll wrote:
OK, I'm now +1 on release
On Feb 1, 2007, at 6:57 AM, Grant Ingersoll wrote:
-1
I would like a few more days to get
https://issues.apache.org/jira/browse/LUCENE-762
Lucene is not a word processor. It is a development library. I think
an understanding of any development library is essential to using it
properly. Once you have even a basic understanding of the Lucene
design, it is very clear as to why deletes are performed using the
IndexReader.
If you
OK folks, please try out the current trunk and see if you see any
problems, or other *bugs* in JIRA that need to go in.
I'll start work on cutting a release tomorrow.
-Yonik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
Any objections to me adding this read-only method to ConstantScoreQuery?
I need to discover RangeFilters etc wrapped in ConstantScoreQuerys as part of a
generic query optimiser/analyser.
Cheers,
Mark
_
Hey Yonik,
Can you make sure the release documentation on the wiki is inline
with what you have to do? I know I had to make some changes for the
website stuff and it may not be 100% correct b/c I didn't run it (#12
at http://wiki.apache.org/jakarta-lucene/ReleaseTodo). Also, you
double
Incorrect parsing by QueryParser.parse() when it encounters backslashes (always
eats one backslash.)
Key: LUCENE-800
URL: https://issues.apache.org/jira/browse/LU
Grant Ingersoll wrote on 13/02/2007 05:27:22:
> Hey Doron,
>
> I did add the dependency for the demo into the build. I suppose,
Yes.. I now see that you added this.
> ideally, the benchmark build would force a build of the top level src
> and demo. If you want to submit a patch for that, I can
build.xml in cnotrib/xml should auto build core java and demo if required
-
Key: LUCENE-801
URL: https://issues.apache.org/jira/browse/LUCENE-801
Project: Lucene - Java
[
https://issues.apache.org/jira/browse/LUCENE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen updated LUCENE-801:
---
Description:
Currently one needs to build core jar and demo jar before building/running
benchmark.
T
[
https://issues.apache.org/jira/browse/LUCENE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen updated LUCENE-801:
---
Summary: build.xml in cnotrib/benchmark should auto build core java and
demo if required (was: build
[
https://issues.apache.org/jira/browse/LUCENE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen updated LUCENE-801:
---
Attachment: build.xml.patch
Tested "run-micro-standard" and "run-task" (also after "clean" from top l
[
https://issues.apache.org/jira/browse/LUCENE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen updated LUCENE-801:
---
Lucene Fields: [Patch Available] (was: [New])
> build.xml in cnotrib/benchmark should auto build cor
[
https://issues.apache.org/jira/browse/LUCENE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-801:
--
Assignee: Grant Ingersoll (was: Doron Cohen)
> build.xml in cnotrib/benchmark should a
[
https://issues.apache.org/jira/browse/LUCENE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-801.
Resolution: Fixed
Committed revision 507260.
Thanks Doron.
> build.xml in cnotrib/benchma
I totally second Robert's thought.
My concern is, to get the raw speed of Lucene, you got to get to the basics.
If we start to apply layers upon layers of code to just mask off the
internals of Lucene, it will not do any good.
An example perhaps is the Windoze vs. Linux. As an end user, you get
On 2/13/07, mark harwood <[EMAIL PROTECTED]> wrote:
Any objections to me adding this read-only method to ConstantScoreQuery?
I need to discover RangeFilters etc wrapped in ConstantScoreQuerys as part of a
generic query optimiser/analyser.
I agree... one should be able to inspect queries and b
21 matches
Mail list logo
