In IndexSearcher class, make subReader and docCount arrays protected so sub
classes can access them
---
Key: LUCENE-1925
URL: https://issues.apache.org/jira/browse/LUC
[
https://issues.apache.org/jira/browse/LUCENE-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated LUCENE-1924:
--
Attachment: BalancedSegmentMergePolicy.java
this is a stand-alone class
> BalancedSegmentMergePolicy,
BalancedSegmentMergePolicy, contributed from the Zoie project for realtime
indexing
---
Key: LUCENE-1924
URL: https://issues.apache.org/jira/browse/LUCENE-1924
Project: L
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758968#action_12758968
]
John Wang commented on LUCENE-1458:
---
This is awesome!
Feel free to take code from Kamika
[
https://issues.apache.org/jira/browse/LUCENE-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758966#action_12758966
]
Lance Norskog commented on LUCENE-1360:
---
Is this code still interesting? That is, ar
> read of such a CSF is not sequential then anymore, because we
> need to seek to each of those file in case of updates.
I think here we'd keep the newly updated blocks in RAM (kind of
like LUCENE-1313 NRT). Where ParallelIndexWriter.commit flushes
the blocks to disk as needed or at a given RAM us
Ya, JTS and GeoTools are great... but they are LGPL.
The original spatial code was based on GeoTools, then any math/spatial
objects were re-factored so the geotools math can be plugged in as
needed. Notice that DistanceUtils can be replaced with something
else that does the math calculat
On Wednesday 23 September 2009 17:29:30 Antonio Iglesias wrote:
> Hi all,
> I'm a java developer and likely I will try to contribute in adding new
> features to Lucene project (I'll try at least) but for the moment I don't
> know much about Lucene what's inside Lucene, I'm been having a look to th
[
https://issues.apache.org/jira/browse/LUCENE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1458:
---
Attachment: LUCENE-1458-back-compat.patch
LUCENE-1458.tar.bz2
New pa
Hi all,
I'm a java developer and likely I will try to contribute in adding new
features to Lucene project (I'll try at least) but for the moment I don't
know much about Lucene what's inside Lucene, I'm been having a look to the
apache site for Lucene and so on but, is there any place with a develo
[
https://issues.apache.org/jira/browse/LUCENE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758717#action_12758717
]
Tim Smith commented on LUCENE-1923:
---
I'll work up a patch that will do the following:
a
I guess that's the big wish we all have! :)
One other big problem with doing inline updates is that we have to
write-once model in Lucene, so we never touch a file after it was written.
My goal is to be able to achieve what you have in mind with CSF and parallel
incremental indexing. When we have
[
https://issues.apache.org/jira/browse/LUCENE-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758712#action_12758712
]
Michael McCandless commented on LUCENE-1923:
+1
> Add toString() or getName()
Has anyone done any work on modifying payloads "inline" in the index?
The idea being that if you know the length of the payload isn't
changing, you can modify it w/o reindexing. Some concerns that come
to mind are thread-safety, etc.
-Grant
---
Add toString() or getName() method to IndexReader
-
Key: LUCENE-1923
URL: https://issues.apache.org/jira/browse/LUCENE-1923
Project: Lucene - Java
Issue Type: Wish
Components: Index
Hi.
I am newbie to lucene.
I have a query to search for a salespersonid and whose contactfirstname is
firstname* and whose whose contactlast name is lastname*
so firstname can be chr* and lastname can be chr* --> so the below query is
retrieving me results chris christopher
QueryParser parser =
[
https://issues.apache.org/jira/browse/LUCENE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch updated LUCENE-486:
-
Component/s: Build
Priority: Trivial (was: Minor)
Fix Version/s: 3.0
> Core Test
[
https://issues.apache.org/jira/browse/LUCENE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch reopened LUCENE-486:
--
Assignee: Michael Busch
> Core Test should not have dependencies on the Demo code
> -
[
https://issues.apache.org/jira/browse/LUCENE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758683#action_12758683
]
Grant Ingersoll commented on LUCENE-486:
+1
> Core Test should not have dependenci
[
https://issues.apache.org/jira/browse/LUCENE-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758677#action_12758677
]
Michael Busch commented on LUCENE-486:
--
I still think we should remove the dependency
[
https://issues.apache.org/jira/browse/LUCENE-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch updated LUCENE-1879:
--
Attachment: parallel_incremental_indexing.tar
MD5 (parallel_incremental_indexing.tar) = b9a928
Hi,
I also tested the whole artifacts, works with 1.5. I do not know if it
prevents us from releasing it, but I am the bad guy and started to use Java
1.4.2 to build and test. Core works perfect, and after removing all contribs
that use -target=1.5 the compilation still fails (there is also the pr
+1
Good job everyone!
On Win XP, Sun JVM 1.6.0_16 I ran the following tests:
lucene-2.9.0.zip:
- ant compile-demo
- ant demo-index-html
- ant demo-search-html
- ant demo-index-text
- ant demo-search-text
- ant jar-demo
- ant war-demo
- ant clean
Everything works fine. The only thing I'm wonder
The cat is awake! And catching up on all these interesting emails...
I think Mark said it all very well :)
The warming you actually do in what you pass to
setMergedSegmentWarmer, I think, should look just like the "normal"
warming you'd do before bringing a newly opened reader into
production.
I forgot to mention, I have a task for 3.0:
https://issues.apache.org/jira/browse/LUCENE-1857
This will add more type safety and then maybe the ctors can be made public
again and the static methods be deprecated/removed. Same for NumericField
and NumericTokenStream. I will do this after commiting
25 matches
Mail list logo
