[jira] Commented: (LUCENE-845) If you "flush by RAM usage" then IndexWriter may over-merge

[ https://issues.apache.org/jira/browse/LUCENE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493065 ] Michael McCandless commented on LUCENE-845: --- > Following up on this, it's basically the idea that segments

how to contribute to lucene-sandbox?

Hi Luceners, I've implemented a package for query expansion in Lucene, using term co-ocurrence frecuencies analysis. I've obtained a real improvement in my experiments using this techniques with Lucene. and I would like include it in Lucene-Sandbox beacuse i think that this implementation will be

how to contribute to lucene-sandbox?

Hi Luceners, I've implemented a package for query expansion in Lucene, using term co-ocurrence frecuencies analysis. I've obtained a real improvement in my experiments using this techniques with Lucene. and I would like include it in Lucene-Sandbox beacuse i think that this implementation will be

[jira] Created: (LUCENE-872) have Hits implement Iterable

have Hits implement Iterable Key: LUCENE-872 URL: https://issues.apache.org/jira/browse/LUCENE-872 Project: Lucene - Java Issue Type: Improvement Components: Search Affects Versions: 2.1 En

Re: how to contribute to lucene-sandbox?

Hola José, Here's a good place to start: In short, put together a patch (including unit tests) against SVN, then create a JIRA issue and attach the patch to it. Steve José Ramón Pérez Agüera wrote: > Hi Luceners, > > I've implemented a pa

Re: [jira] Created: (LUCENE-854) Create merge policy that doesn't periodically inadvertently optimize

On 3/31/07, Michael McCandless (JIRA) <[EMAIL PROTECTED]> wrote: Create merge policy that doesn't periodically inadvertently optimize So we could make a small change to the policy by only merging the first mergeFactor segments o

Re: [jira] Commented: (LUCENE-847) Factor merge policy out of IndexWriter

On 3/23/07, Steven Parkes (JIRA) <[EMAIL PROTECTED]> wrote: In fact, there a few things here that are fairly subtle/important. The relationship/protocol between the writer and policy is pretty strong. This can be seen in the strawman concurrent merge code where the merge policy holds state and

common-build.xml missing from nightly build

I get the following error when trying to build from the nightly source (http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/75/artifact/trunk/dist/lucene-nightly.tar.gz) C:\download\lucene-nightly\build.xml:7: Cannot find common-build.xml imported from C:\download\lucene-nightly\b

[jira] Created: (LUCENE-873) nightly builds depend on clover

nightly builds depend on clover --- Key: LUCENE-873 URL: https://issues.apache.org/jira/browse/LUCENE-873 Project: Lucene - Java Issue Type: Bug Reporter: Hoss Man as reported by Michael Pelz Sherman

[jira] Updated: (LUCENE-848) Add supported for Wikipedia English as a corpus in the benchmarker stuff

[ https://issues.apache.org/jira/browse/LUCENE-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Parkes updated LUCENE-848: - Lucene Fields: [Patch Available] > Add supported for Wikipedia English as a corpus in the benchma

[jira] Commented: (LUCENE-872) have Hits implement Iterable

[ https://issues.apache.org/jira/browse/LUCENE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493236 ] DM Smith commented on LUCENE-872: - This will need to wait until Java 1.4.2 is no longer our target language. > have

RE: [jira] Created: (LUCENE-854) Create merge policy that doesn't periodically inadvertently optimize

As I understand it (correct me if I'm wrong, Mike), there will be a cascading merge in this case, but not an optimize, because you don't merge all (twenty) segments at each level, just half of them (ten). -Original Message- From: Ning Li [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 02,

RE: [jira] Commented: (LUCENE-847) Factor merge policy out of IndexWriter

By atomic, I meant that the writer knows the policy and the policy knows the writer, that it wouldn't be possible for to set a merge policy on a writer without the merge policy "knowing" that. It's easy enough to implement with Chris's code (which, I think, makes it a compile error) or with a simpl

Re: How To find which field has the search term in Hit?

Hi, Could you find out a solution to your problem ? Even I am facing a similar problem. If you use highlighting and finding which field contains the search term, it is possible, However it is very performance intensive. Any other solution ? -thanks N-3 wrote: > > Hi > > I am searching on m

[jira] Updated: (LUCENE-446) FunctionQuery - score based on field value

[ https://issues.apache.org/jira/browse/LUCENE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-446: --- Attachment: function.patch.txt Attached function.patch.txt adds three new queries: 1. ValueSourceQue

[jira] Updated: (LUCENE-446) search.function - (1) score based on field value, (2) simple score customizability

[ https://issues.apache.org/jira/browse/LUCENE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-446: --- Priority: Minor (was: Major) Lucene Fields: [Patch Available] Affects Version/s:

[jira] Assigned: (LUCENE-850) Easily create queries that transform subquery scores arbitrarily

[ https://issues.apache.org/jira/browse/LUCENE-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen reassigned LUCENE-850: -- Assignee: Doron Cohen > Easily create queries that transform subquery scores arbitrarily >

Re: [jira] Created: (LUCENE-854) Create merge policy that doesn't periodically inadvertently optimize

"Ning Li" <[EMAIL PROTECTED]> wrote: > On 3/31/07, Michael McCandless (JIRA) <[EMAIL PROTECTED]> wrote: > > Create merge policy that doesn't periodically inadvertently optimize > > > > So we could make a small change to the polic

[jira] Commented: (LUCENE-872) have Hits implement Iterable

[ https://issues.apache.org/jira/browse/LUCENE-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493289 ] Mark Harwood commented on LUCENE-872: - I have some reservations about making it even easier for new Lucene users