Question about aborting background merges
Hi, I have a question about IndexWriter.close(false) and background merges. I was going to take a look at the code, but I'm sure that Mike knows the answer :-). Let's assume that a long background merge is going on and close(false) is called. Then the merges are marked as aborted and IndexWriter.close() returns after flushing DocumentsWriter's buffers. The background merge threads keep going. Now a new IndexWriter is opened and optimize() is called. Can it happen that optimize() tries to create a segment with the same name the background threads are still working on? Then the new IndexWriter would probably hit an IOException? Or would the new IndexWriter use different file names for the merged segments? -Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (LUCENE-935) Improve maven artifacts
[ https://issues.apache.org/jira/browse/LUCENE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch resolved LUCENE-935. -- Resolution: Fixed I just committed the latest patch. OK, I think I can close this issue now. We have made good progress with the maven artifacts since we released 2.2. The artifacts include the sources and javadocs now and we're deploying nightly snapshots to the m2 snapshot repository. Thanks, Grant, and everyone else who helped here!! > Improve maven artifacts > --- > > Key: LUCENE-935 > URL: https://issues.apache.org/jira/browse/LUCENE-935 > Project: Lucene - Java > Issue Type: Improvement > Components: Build >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Attachments: lucene-935-new.patch, lucene-935-remote-repos.patch, > lucene-935-rename-poms.patch, lucene-935.patch > > > There are a couple of things we can improve for the next release: > - "*pom.xml" files should be renamed to "*pom.xml.template" > - artifacts "lucene-parent" should extend "apache-parent" > - add source jars as artifacts > - update task to work with latest version of > maven-ant-tasks.jar > - metadata filenames should not contain "local" -- 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-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Busch updated LUCENE-584:
-
Attachment: lucene-584-take2.patch
OK, here's a new version of the patch.
Changes:
- Removed MatchFilter entirely.
- Filter.bits(IndexReader) is now deprecated and not abstract anymore.
Filter.bits(IndexReader) returns null, and Filter.matcher(IndexReader)
returns the new BitSetMatcher. This allows to create new Filters that
only implement the new getMatcher(IndexReader) method. Existing filters
on the other hand will still work together with the BitSetMatcher.
- The new class BitSetFilter extends Filter and defines the abstract
method bits(IndexReader), just as Filter did before this patch.
- I deprecated also CachingWrapperFilter and RemoteCachingWrapperFilter
and added corresponding CachingBitSetFilter and RemoteCachingBitSetFilter
which do essentially the same but only accept BitSetFilters.
All testcases pass and believe this should be fully backwards compatible.
Also, all core classes that call Filter.bits() are deprecated themselves.
In Lucene 3.0 we should make the following changes:
- Remove Filter.bits() and define Filter.getMatcher() abstract.
- Remove CachingWrapperFilter and RemoteCachingWrapperFilter
(and corresponding testcases)
- Add new matchers, like the OpenBitSetMatcher and SortedVIntMatcher
and add the DefaultMatcher class. (these classes are all located in
Paul's patch files)
> 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
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584-take2.patch,
> lucene-584.patch, Matcher-20070905-2default.patch,
> Matcher-20070905-3core.patch, Matcher-20071122-1ground.patch, Some
> Matchers.zip
>
>
> {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-1045) SortField.AUTO doesn't work with long
[ https://issues.apache.org/jira/browse/LUCENE-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547715 ] Yonik Seeley commented on LUCENE-1045: -- I think we should just fold Long & Double support into the FieldCache and change it to be an abstract class. It is *very* unlikely that anyone has implemented their own FieldCache since it wouldn't be directly usable with Lucene. In the worst-case scenario that someone did, there will be an immediate and understandable error, and the fix is easy. > 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 >Priority: Minor > Fix For: 2.3 > > Attachments: auto-long-sorting.diff, 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]
[jira] Commented: (LUCENE-1045) SortField.AUTO doesn't work with long
[ https://issues.apache.org/jira/browse/LUCENE-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547714 ] Grant Ingersoll commented on LUCENE-1045: - Any more thoughts on this? Otherwise, I am going to apply this patch before I forget about it. It does seem to me there is at least a remote possibility of using the interface. I will commit tomorrow evening or Tuesday unless I hear otherwise. > 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 >Priority: Minor > Fix For: 2.3 > > Attachments: auto-long-sorting.diff, 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]
[jira] Commented: (LUCENE-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547691
]
Paul Elschot commented on LUCENE-584:
-
I had not thought about deprecating yet, but it should work nicely.
I suppose you want to add a class BitSetFilter (subclass of Filter) as the
preferred alternative
to the deprecated method?
Initially Filter and BitSetFilter would be very similar, except that
Filter.bits() would be deprecated.
Later, after removal of Filter.bits(), Filter.getMatcher() would be declared
abstract.
I tried to do something pretty close to this for contrib/xml-query-parser, but
I could not make that work,
which is why I changed to adding a new superclass MatchFilter.
Nevertheless, I think the deprecation above should work, but at the moment I
can't foresee the consequences.
> 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
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {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-tabpanel#action_12547689
]
Michael Busch commented on LUCENE-584:
--
What about adding the getMatcher() method to Filter and
deprecating bits(IndexReader)? Then when we release
3.0 we can remove bits() and the only method in Filter
will be getMatcher().
Then this patch should be backwards compatible
and we'd do the API change with the next major release.
Any objections?
> 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
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {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] Updated: (LUCENE-935) Improve maven artifacts
[ https://issues.apache.org/jira/browse/LUCENE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Busch updated LUCENE-935: - Attachment: lucene-935-remote-repos.patch Hey Grant, can you try out this patch. It should make our life easier, I think I got the remote repos deployment to work in the ant script. Try this (just replace my username) : ant -Dm2.repository.url=scp://people.apache.org:/www/people.apache.org/maven-snapshot-repository -Dm2.repository.username=buschmi -Dm2.repository.private.key=/export/home/buschmi/.ssh/id_dsa -Dversion=2.3-SNAPSHOT clean generate-maven-artifacts > Improve maven artifacts > --- > > Key: LUCENE-935 > URL: https://issues.apache.org/jira/browse/LUCENE-935 > Project: Lucene - Java > Issue Type: Improvement > Components: Build >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Attachments: lucene-935-new.patch, lucene-935-remote-repos.patch, > lucene-935-rename-poms.patch, lucene-935.patch > > > There are a couple of things we can improve for the next release: > - "*pom.xml" files should be renamed to "*pom.xml.template" > - artifacts "lucene-parent" should extend "apache-parent" > - add source jars as artifacts > - update task to work with latest version of > maven-ant-tasks.jar > - metadata filenames should not contain "local" -- 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] Issue Comment Edited: (LUCENE-584) Decouple Filter from BitSet
[
https://issues.apache.org/jira/browse/LUCENE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547686
]
[EMAIL PROTECTED] edited comment on LUCENE-584 at 12/2/07 3:04 PM:
--
For example, OpenBitSetFilter would like this:
{code}
class OpenBitSetFilter /* ... */ {
OpenBitSet bits(reader) { ... }
Matcher getMatcher(reader) { ... }
}
{code}
Since the only thing needed by an IndexSearcher would be the Matcher,
MatchFilteris what Filter and OpenBitSetFilter have in common:
the getMatcher() method.
was (Author: [EMAIL PROTECTED]):
For example, OpenBitSetFilter would like this:
{code}
class OpenBitSetFilter /* ... */ {
OpenBitSet bits(reader) { ... }
Matcher getMatcher(reader) { ... }
}
{code}
Since the only thing needed by an IndexSearcher would be the Matcher,
MatchFilter what Filter and OpenBitSetFilter have in common, the getMatcher()
method.
> 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
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {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-tabpanel#action_12547686
]
Paul Elschot commented on LUCENE-584:
-
For example, OpenBitSetFilter would like this:
{code}
class OpenBitSetFilter /* ... */ {
OpenBitSet bits(reader) { ... }
Matcher getMatcher(reader) { ... }
}
{code}
Since the only thing needed by an IndexSearcher would be the Matcher,
MatchFilter what Filter and OpenBitSetFilter have in common, the getMatcher()
method.
> 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
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {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-tabpanel#action_12547681
]
Michael Busch commented on LUCENE-584:
--
Why do we actually need the new MatchFilter class at all?
Filter is an abstract class, not an interface. So I think we could
simply add the new method getMatcher() like you already did
in your patch:
{code:java}
/**
* @return A Matcher constructed from the provided BitSet.
* @seeDefaultMatcher#defaultMatcher(BitSet)
*/
public Matcher getMatcher(IndexReader reader) throws IOException {
return new BitSetMatcher(bits(reader));
}
{code}
This shouldn't break existing Filter implementations?
Maybe I'm missing an apparent reason why we need the MatchFilter
class?
> 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
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {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] Assigned: (LUCENE-1019) CustomScoreQuery should support multiple ValueSourceQueries
[ https://issues.apache.org/jira/browse/LUCENE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen reassigned LUCENE-1019: --- Assignee: Doron Cohen > CustomScoreQuery should support multiple ValueSourceQueries > --- > > Key: LUCENE-1019 > URL: https://issues.apache.org/jira/browse/LUCENE-1019 > Project: Lucene - Java > Issue Type: Improvement > Components: Search >Affects Versions: 2.2 >Reporter: Kyle Maxwell >Assignee: Doron Cohen > Attachments: CustomMultiQuery.v0.diff, CustomScoreQuery.v1.diff > > > CustomScoreQuery's constructor currently accepts a subQuery, and a > ValueSourceQuery. I would like it to accept multiple ValueSourceQueries. > The workaround of nested CustomScoreQueries works for simple cases, but it > quickly becomes either cumbersome to manage, or impossible to implement the > desired function. > This patch implements CustomMultiScoreQuery with my desired functionality, > and refactors CustomScoreQuery to implement the special case of a > CustomMultiScoreQuery with 0 or 1 ValueSourceQueries. This keeps the > CustomScoreQuery API intact. > This patch includes basic tests, more or less taken from the original > implementation, and customized a bit to cover the new cases. -- 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-1019) CustomScoreQuery should support multiple ValueSourceQueries
[
https://issues.apache.org/jira/browse/LUCENE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547673
]
Doron Cohen commented on LUCENE-1019:
-
{quote}
* The way in which caching is handled is now unclear.
{quote}
For e.g. IntFieldSource caching is done in that level, so I am not sure
I understand about what is unclear here.
{quote}
* Trying to get explain information from the sub-ValueSources was quite
difficult.
* There is much more code in my queries, leading to increased brittleness.
{quote}
Yes I agree about this part.
I had the similar experience when combining field values, and decided to just
live with that.
In a glance, the v2 patch seems to solve this nicely so I will look into
committing this.
Thanks for bringing this up,
Doron
> CustomScoreQuery should support multiple ValueSourceQueries
> ---
>
> Key: LUCENE-1019
> URL: https://issues.apache.org/jira/browse/LUCENE-1019
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
>Affects Versions: 2.2
>Reporter: Kyle Maxwell
> Attachments: CustomMultiQuery.v0.diff, CustomScoreQuery.v1.diff
>
>
> CustomScoreQuery's constructor currently accepts a subQuery, and a
> ValueSourceQuery. I would like it to accept multiple ValueSourceQueries.
> The workaround of nested CustomScoreQueries works for simple cases, but it
> quickly becomes either cumbersome to manage, or impossible to implement the
> desired function.
> This patch implements CustomMultiScoreQuery with my desired functionality,
> and refactors CustomScoreQuery to implement the special case of a
> CustomMultiScoreQuery with 0 or 1 ValueSourceQueries. This keeps the
> CustomScoreQuery API intact.
> This patch includes basic tests, more or less taken from the original
> implementation, and customized a bit to cover the new cases.
--
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-1073) Add unit test showing how to do a "live backup" of an index
[
https://issues.apache.org/jira/browse/LUCENE-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1073:
---
Attachment: LUCENE-1073.take3.patch
Thanks for reviewing Michael!
{quote}
Maybe we should add SnapshotDeletionPolicy to the core (now it's an
inner class in the test case). I bet people would like to use it when
they implement backup functionalities in their apps.
{quote}
OK I think that makes sense.
I also found & fixed some thread safety issues with the test and added
a missing synchronized in DocumentsWriter that the test uncovered.
Attached new patch with these changes. I plan to commit in a day or
two.
> Add unit test showing how to do a "live backup" of an index
> ---
>
> Key: LUCENE-1073
> URL: https://issues.apache.org/jira/browse/LUCENE-1073
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Examples
>Affects Versions: 2.2
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.3
>
> Attachments: LUCENE-1073.patch, LUCENE-1073.take2.patch,
> LUCENE-1073.take3.patch
>
>
> The question of how to backup an index comes up every so often on the
> lists. Backing up and index is also clearly an important fundamental
> admin task that many applications need to do for fault tolerance.
> In the past you were forced to stop & block all changes to your index,
> perform the backup, and then resume changes. But many applications
> cannot afford a potentially long pause in their indexing.
> With the addition of DeletionPolicy (LUCENE-710), it's now possible to
> do a "live backup", which means backup your index in the background
> without pausing ongoing changes to the index. This
> SnapshotDeletionPolicy just has to mark the chosen commit point as not
> deletable, until the backup finishes.
--
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]
FYI: svn commit: r600373 - in /lucene/java/trunk/docs: mailinglists.html mailinglists.pdf
I started a Wiki page listing Mailing List Archives at http://wiki.apache.org/lucene-java/MailingListArchives if anyone is wondering why they are no longer listed in the main site documentation. If you have an archive of Lucene's mailing lists, please feel free to add it there. Begin forwarded message: From: [EMAIL PROTECTED] Date: December 2, 2007 3:37:52 PM EST To: [EMAIL PROTECTED] Subject: svn commit: r600373 - in /lucene/java/trunk/docs: mailinglists.html mailinglists.pdf Reply-To: java-dev@lucene.apache.org Author: gsingers Date: Sun Dec 2 12:37:52 2007 New Revision: 600373 URL: http://svn.apache.org/viewvc?rev=600373&view=rev Log: altered info about mailing list archives Modified: lucene/java/trunk/docs/mailinglists.html lucene/java/trunk/docs/mailinglists.pdf Modified: lucene/java/trunk/docs/mailinglists.html URL: http://svn.apache.org/viewvc/lucene/java/trunk/docs/mailinglists.html?rev=600373&r1=600372&r2=600373&view=diff = = = = = = = = == --- lucene/java/trunk/docs/mailinglists.html (original) +++ lucene/java/trunk/docs/mailinglists.html Sun Dec 2 12:37:52 2007 @@ -310,6 +310,9 @@ Java Developer List +Mail Archives + + Other Mailing Lists @@ -334,23 +337,18 @@ -http://mail-archives.apache.org/mod_mbox/lucene-java- user/">Archive - (http://mail-archives.apache.org/mod_mbox/jakarta-lucene-user/ ">old archive) - - -http://www.gossamer-threads.com/lists/lucene/java- user/">Alternative -archive with search feature - +http://mail-archives.apache.org/mod_mbox/lucene-java- user/">Official Archive + (http://mail-archives.apache.org/mod_mbox/jakarta-lucene-user/ ">Old Jakarta Archive) - + Java Developer List This is the list where participating developers of the Java Lucene project meet - and discuss issues, code changes/additions, etc. Do not send mail to this list + and discuss issues concerning Lucene internals, code changes/additions, etc. Do not send mail to this list with usage questions or configuration questions and problems. @@ -367,13 +365,8 @@ -http://mail-archives.apache.org/mod_mbox/lucene-java- dev/">Archive -(http://mail-archives.apache.org/mod_mbox/jakarta-lucene-dev/ ">old archive) - - -http://www.gossamer-threads.com/lists/lucene/java- dev/">Alternative - archive with search feature - +http://mail-archives.apache.org/mod_mbox/lucene-java- dev/">Official Archive +(http://mail-archives.apache.org/mod_mbox/jakarta-lucene-dev/ ">Old Jakarta Archive) @@ -396,8 +389,15 @@ + + +Mail Archives + +The Lucene Wiki maintains a list of Lucene mailing list archives at http://wiki.apache.org/lucene-java/MailingListArchives";>http://wiki.apache.org/lucene-java/MailingListArchives . +No endorsement is implied by the listing of an archive on the Wiki. + - + Other Mailing Lists Each Lucene project maintains its own mailing lists. Please refer to the project you are interested in for details Modified: lucene/java/trunk/docs/mailinglists.pdf URL: http://svn.apache.org/viewvc/lucene/java/trunk/docs/mailinglists.pdf?rev=600373&r1=600372&r2=600373&view=diff = = = = = = = = == --- lucene/java/trunk/docs/mailinglists.pdf (original) +++ lucene/java/trunk/docs/mailinglists.pdf Sun Dec 2 12:37:52 2007 @@ -5,10 +5,10 @@ /Producer (FOP 0.20.5) >> endobj 5 0 obj -<< /Length 452 /Filter [ /ASCII85Decode /FlateDecode ] +<< /Length 490 /Filter [ /ASCII85Decode /FlateDecode ] stream -Gb!#X4\rsL&Dcq.DG5g,rlF22Ud0\BKFhQA$mp,N80KER>/\0':*]+KWL/Q +jIZ+Pmrt2&*'CXfK.>$<>!(N6mFhlZ6+Z96,N,?dOW$ZA>_WKk<5"VcE\^jJS_H-)X %l_k4p'#io5Q*N6K/[EMAIL PROTECTED]'ggr.g?+2<]:e^=sbqVG_si*KL1o8#k5fY(SjGReg8VRi388J\CGq3f %Y[^Kt0J>(C)oC)f(W"*H9Ylh8ZSKq6-n$m:@9q1-SfJ*OnbUc_62NG2b'iL`dOPb"rX +)KP;gS!iCT^KrXR721j4qj[qUOqj]._ \o/+\'gX]/BO'fsCXdXjcsFg1:\Ej&PX9E,$CD$3E~> +Gb!#X9iHZu&[EMAIL PROTECTED],^"o?#%X%UPF(*R0CY9iF1(#C";6MgLZhh!&D/uW8H2KlopR66E\Dt,*B*=p +"*JF_4:dupoPBr9>0FfWL5,6frEKC-\7H0I$?=U:f8#,0d!gNljQ#s\'aNOMbV%N7b&j6> \5Z`nIhVc7!crI@,S>)'f\]Anm^&t=QiZuDH*NkCB"g?cjbYX;1M7a,:>[WJ;)PrZD"n/ P:Z0%F5bkd_3)A)%Q;(@r(BT.G`E]s[0)m"]*+ +4H)k`d3R:b,)[EMAIL PROTECTED]"1%Z`E*9ATeFg_7Lo3Koc5C6h %RYVR8R4,@8o%Z'oWjM_`CMRK]*Qi6Sk#I8hZ(`qg:qNuAeb`4A[V2Uh"#-u;XT~> endstream endobj 6 0 obj @@ -25,6 +25,7 @@ 8 0 R 10 0 R 12 0 R +14 0 R ] endobj 8 0 obj @@ -50,7 +51,7 @@ 12 0 obj << /Type /Annot /Subtype /Link -/Rect [ 102.0 523.266 204.668 511.266 ] +/Rect [ 102.0 523.266 178.988 511.266 ] /C [ 0 0 0 ] /Border [ 0 0 0 ] /A 13 0 R @@ -58,71 +59,89 @@ endobj 14 0 obj -<< /Length 1393 /Filter [ /ASCII85Decode /FlateDecode ] +<< /Type /Annot +/Subtype /Link +/Rect [ 102.0 505.066 204.668 493.066 ] +/C [ 0 0 0 ] +/Border [ 0 0 0 ] +/A 15 0 R +/H /I +>> +endobj
[jira] Commented: (LUCENE-935) Improve maven artifacts
[ https://issues.apache.org/jira/browse/LUCENE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547662 ] Grant Ingersoll commented on LUCENE-935: Added the note to the release TODO on the Wiki > Improve maven artifacts > --- > > Key: LUCENE-935 > URL: https://issues.apache.org/jira/browse/LUCENE-935 > Project: Lucene - Java > Issue Type: Improvement > Components: Build >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Attachments: lucene-935-new.patch, lucene-935-rename-poms.patch, > lucene-935.patch > > > There are a couple of things we can improve for the next release: > - "*pom.xml" files should be renamed to "*pom.xml.template" > - artifacts "lucene-parent" should extend "apache-parent" > - add source jars as artifacts > - update task to work with latest version of > maven-ant-tasks.jar > - metadata filenames should not contain "local" -- 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-935) Improve maven artifacts
[ https://issues.apache.org/jira/browse/LUCENE-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547661 ] Grant Ingersoll commented on LUCENE-935: I have changed the nightly.sh to output these now as 2.3-SNAPSHOT. I don't know how to get it to recognize the version number in the build file with out somehow slurping it from that file (not worth the effort), so instead, I will add to the release notes that the nightly.sh file needs to be updated upon release > Improve maven artifacts > --- > > Key: LUCENE-935 > URL: https://issues.apache.org/jira/browse/LUCENE-935 > Project: Lucene - Java > Issue Type: Improvement > Components: Build >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Attachments: lucene-935-new.patch, lucene-935-rename-poms.patch, > lucene-935.patch > > > There are a couple of things we can improve for the next release: > - "*pom.xml" files should be renamed to "*pom.xml.template" > - artifacts "lucene-parent" should extend "apache-parent" > - add source jars as artifacts > - update task to work with latest version of > maven-ant-tasks.jar > - metadata filenames should not contain "local" -- 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-tabpanel#action_12547612
]
Paul Elschot commented on LUCENE-584:
-
I tried implementing a Searchable, and indeed ran into compilation errors.
So, backward compatibility is indeed not complete.
Also, Searchable is an interface, so it should not be changed.
In case there are other interfaces affected by the patch these should not be
changed either.
There are two ways out of this:
Do a name change on MatcherFilter/Filter -> Filter/BitSetFilter.
Changing the current Filter to BitSetFilter gives other problems with contrib
packages.
I tried this some time ago, see above, but I could not make it work.
I'd prefer to add an interface (or abstract class?) like Searchable that uses
MatchFilter for those implementers that want to take advantage of MatchFilter.
I don't expect problems from leaving the Searchable interface available
unchanged.
Other interfaces that use Filter can be treated the same way, in case there are
any.
> 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
> Attachments: bench-diff.txt, bench-diff.txt, lucene-584.patch,
> Matcher-20070905-2default.patch, Matcher-20070905-3core.patch,
> Matcher-20071122-1ground.patch, Some Matchers.zip
>
>
> {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]
