Re: broken links for javadocs (redirects pointed at old zone)
Michael Busch wrote: Doug Cutting wrote: /www/lucene.apache.org/java/docs/api/.htaccess /www/lucene.apache.org/java/docs/nightly/api/.htaccess I just changed these to files to redirect to the new location: http://hudson.zones.apache.org/hudson/job/Lucene-trunk/javadoc/. Are these in subversion? They should be. Note that, it is often easier to maintain fewer .htaccess files higher in the tree. These redirects could both instead be in: http://svn.apache.org/repos/asf/lucene/java/site/docs/.htaccess Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564878#action_12564878
]
Michael Busch commented on LUCENE-584:
--
Thanks, Paul for testing and reviewing.
I'll correct the javadocs.
OK, I will commit this tomorrow if nobody objects!
Decouple Filter from BitSet
---
Key: LUCENE-584
URL: https://issues.apache.org/jira/browse/LUCENE-584
Project: Lucene - Java
Issue Type: Improvement
Components: Search
Affects Versions: 2.0.1
Reporter: Peter Schäfer
Assignee: Michael Busch
Priority: Minor
Fix For: 2.4
Attachments: bench-diff.txt, bench-diff.txt,
ContribQueries20080111.patch, lucene-584-take2.patch,
lucene-584-take3-part1.patch, lucene-584-take3-part2.patch,
lucene-584-take4-part1.patch, lucene-584-take4-part2.patch,
lucene-584-take5-part1.patch, lucene-584-take5-part2.patch, lucene-584.patch,
Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
Matcher-20071122-1ground.patch, Some Matchers.zip, Test20080111.patch
{code}
package org.apache.lucene.search;
public abstract class Filter implements java.io.Serializable
{
public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
}
public interface AbstractBitSet
{
public boolean get(int index);
}
{code}
It would be useful if the method =Filter.bits()= returned an abstract
interface, instead of =java.util.BitSet=.
Use case: there is a very large index, and, depending on the user's
privileges, only a small portion of the index is actually visible.
Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
memory. It would be desirable to have an alternative BitSet implementation
with smaller memory footprint.
Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
obviously not designed for that purpose.
That's why I propose to use an interface instead. The default implementation
could still delegate to =java.util.BitSet=.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564875#action_12564875
]
Paul Elschot commented on LUCENE-584:
-
The take5 patch tests ok here.
One very minor remark: the javadoc at RangeFilter.getDocIdSet still mentions
BitSet.
Decouple Filter from BitSet
---
Key: LUCENE-584
URL: https://issues.apache.org/jira/browse/LUCENE-584
Project: Lucene - Java
Issue Type: Improvement
Components: Search
Affects Versions: 2.0.1
Reporter: Peter Schäfer
Assignee: Michael Busch
Priority: Minor
Fix For: 2.4
Attachments: bench-diff.txt, bench-diff.txt,
ContribQueries20080111.patch, lucene-584-take2.patch,
lucene-584-take3-part1.patch, lucene-584-take3-part2.patch,
lucene-584-take4-part1.patch, lucene-584-take4-part2.patch,
lucene-584-take5-part1.patch, lucene-584-take5-part2.patch, lucene-584.patch,
Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
Matcher-20071122-1ground.patch, Some Matchers.zip, Test20080111.patch
{code}
package org.apache.lucene.search;
public abstract class Filter implements java.io.Serializable
{
public abstract AbstractBitSet bits(IndexReader reader) throws IOException;
}
public interface AbstractBitSet
{
public boolean get(int index);
}
{code}
It would be useful if the method =Filter.bits()= returned an abstract
interface, instead of =java.util.BitSet=.
Use case: there is a very large index, and, depending on the user's
privileges, only a small portion of the index is actually visible.
Sparsely populated =java.util.BitSet=s are not efficient and waste lots of
memory. It would be desirable to have an alternative BitSet implementation
with smaller memory footprint.
Though it _is_ possibly to derive classes from =java.util.BitSet=, it was
obviously not designed for that purpose.
That's why I propose to use an interface instead. The default implementation
could still delegate to =java.util.BitSet=.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-1160) MergeException from CMS threads should record the Directory
[ https://issues.apache.org/jira/browse/LUCENE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-1160. Resolution: Fixed MergeException from CMS threads should record the Directory --- Key: LUCENE-1160 URL: https://issues.apache.org/jira/browse/LUCENE-1160 Project: Lucene - Java Issue Type: Improvement Components: Index Affects Versions: 2.3 Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Fix For: 2.4 Attachments: LUCENE-1160.patch When you hit an unhandled exception in ConcurrentMergeScheduler, it throws a MergePolicy.MergeException, but there's no easy way to figure out which index caused this (if you have more than one). I plan to add the Directory to the MergeException. I also made a few other small changes to ConcurrentMergeScheduler: * Added handleMergeException method, which is called on exception, so that you can subclass ConcurrentMergeScheduler to do something when an exception occurs. * Added getMergeThread() method so you can override how the threads are created (eg, if you want to make them in a different thread group, use a pool, change priorities, etc.). * Added doMerge(...) to actually do this merge, so you can do something before starting and after finishing a merge. * Changed private - protected on a few attrs I plan to commit in a day or two. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-831) Complete overhaul of FieldCache API/Implementation
[ https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch updated LUCENE-831: - Description: Motivation: 1) Complete overhaul the API/implementation of FieldCache type things... a) eliminate global static map keyed on IndexReader (thus eliminating synch block between completley independent IndexReaders) b) allow more customization of cache management (ie: use expiration/replacement strategies, disk backed caches, etc) c) allow people to define custom cache data logic (ie: custom parsers, complex datatypes, etc... anything tied to a reader) d) allow people to inspect what's in a cache (list of CacheKeys) for an IndexReader so a new IndexReader can be likewise warmed. e) Lend support for smarter cache management if/when IndexReader.reopen is added (merging of cached data from subReaders). 2) Provide backwards compatibility to support existing FieldCache API with the new implementation, so there is no redundent caching as client code migrades to new API. was: Motivation: 1) Complete overhaul the API/implementation of FieldCache type things... a) eliminate global static map keyed on IndexReader (thus eliminating synch block between completley independent IndexReaders) b) allow more customization of cache management (ie: use expiration/replacement strategies, disk backed caches, etc) c) allow people to define custom cache data logic (ie: custom parsers, complex datatypes, etc... anything tied to a reader) d) allow people to inspect what's in a cache (list of CacheKeys) for an IndexReader so a new IndexReader can be likewise warmed. e) Lend support for smarter cache management if/when IndexReader.reopen is added (merging of cached data from subReaders). 2) Provide backwards compatibility to support existing FieldCache API with the new implementation, so there is no redundent caching as client code migrades to new API. Fix Version/s: 2.4 Complete overhaul of FieldCache API/Implementation -- Key: LUCENE-831 URL: https://issues.apache.org/jira/browse/LUCENE-831 Project: Lucene - Java Issue Type: Improvement Components: Search Reporter: Hoss Man Assignee: Michael Busch Fix For: 2.4 Attachments: fieldcache-overhaul.diff, fieldcache-overhaul.diff Motivation: 1) Complete overhaul the API/implementation of FieldCache type things... a) eliminate global static map keyed on IndexReader (thus eliminating synch block between completley independent IndexReaders) b) allow more customization of cache management (ie: use expiration/replacement strategies, disk backed caches, etc) c) allow people to define custom cache data logic (ie: custom parsers, complex datatypes, etc... anything tied to a reader) d) allow people to inspect what's in a cache (list of CacheKeys) for an IndexReader so a new IndexReader can be likewise warmed. e) Lend support for smarter cache management if/when IndexReader.reopen is added (merging of cached data from subReaders). 2) Provide backwards compatibility to support existing FieldCache API with the new implementation, so there is no redundent caching as client code migrades to new API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating Lucene Index with Unstored fields
thanks for your quick reply.
I'm trying to use your method, but running into a NullPointerException on
the IndexWriteer.addIndexes().
code sample
isearcher is IndexSearcher,
newValues is IndexWriter with RAM Directory
snip
ParallelReader preader = new ParallelReader();
preader.add(isearcher.getIndexReader());
preader.add(new
IndexSearcher(newValues.getDirectory()).getIndexReader());
int numdoc = preader.numDocs();
for (int i = 0; i numdoc; i++){
Document d= preader.document(i);
System.out.println( d.toString());
}
writer.addIndexes(new IndexReader[]{preader});
snip
this code works fine before the addIndexes line.
it printed the merged index properly.
but addIndexes throws NullPointerException.
java.lang.NullPointerException
at
org.apache.lucene.index.ParallelReader$ParallelTermPositions.seek(ParallelReader.java:358)
at
org.apache.lucene.index.ParallelReader$ParallelTermDocs.seek(ParallelReader.java:320)
at
org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:327)
at
org.apache.lucene.index.SegmentMerger.mergeTermInfo(SegmentMerger.java:298)
at
org.apache.lucene.index.SegmentMerger.mergeTermInfos(SegmentMerger.java:272)
at
org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:236)
at
org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:89)
at
org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:605)
I was using lucene 1.9.1, but there's a bug for this ,and i've updated to
lucene 2.0.0,
but still the same.
thanks in advance,
Philip
Andrzej Bialecki wrote:
philipc wrote:
hi,
I'm trying to add a new field to all the documents in a lucene index.
After searching around, I found the only way to do an update
is by retrieve the old documents, update it, delete it, then re-add
to index.
However, this worked for only preserving the stored fields.
i've lost all the unstored fields from the documents.
is there anyway to keep the unstored fields as well?
Or any way to go around the problem,
ie, anyway to export the entire index to a csv file
and then update the cvs, and then import it back?
Here's an idea: create an index consisting of documents with just this
field, adding documents in exactly the same order as they are in the
other index. Then use ParallelReader to access both indexes at the same
time - ParallelReader will present a merged view of both indexes. You
can also use IndexWriter.addIndexes() to create a merged index.
--
Best regards,
Andrzej Bialecki
___. ___ ___ ___ _ _ __
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Updating-Lucene-Index-with-Unstored-fields-tp15188818p15236124.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-1045) SortField.AUTO doesn't work with long
[ https://issues.apache.org/jira/browse/LUCENE-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved LUCENE-1045. - Resolution: Fixed Fix Version/s: (was: 2.3) 2.4 I committed the short-byte patch. SortField.AUTO doesn't work with long - Key: LUCENE-1045 URL: https://issues.apache.org/jira/browse/LUCENE-1045 Project: Lucene - Java Issue Type: Bug Components: Search Affects Versions: 2.2 Reporter: Daniel Naber Assignee: Grant Ingersoll Priority: Minor Fix For: 2.4 Attachments: auto-long-sorting.diff, LUCENE-1045-shortbyte.patch, LUCENE-1045.patch, LUCENE-1045.patch, TestDateSort.java This is actually the same as LUCENE-463 but I cannot find a way to re-open that issue. I'm attaching a test case by dragon-fly999 at hotmail com that shows the problem and a patch that seems to fix it. The problem is that a long (as used for dates) cannot be parsed as an integer, and the next step is then to parse it as a float, which works but which is not correct. With the patch the following parsers are used in this order: int, long, float. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
