[jira] Reopened: (LUCENE-1019) CustomScoreQuery should support multiple ValueSourceQueries
[ https://issues.apache.org/jira/browse/LUCENE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyle Maxwell reopened LUCENE-1019: -- Lucene Fields: [New, Patch Available] Hi, after trying out the combined valuesource implementation suggested by Doron, I've found it to be _extremely_ cumbersome and brittle in practice. Therefore, I am reopening this ticket. - Trying to get explain information from the sub-ValueSources was quite difficult. - There is much more code in my queries, leading to increased brittleness. - The way in which caching is handled is now unclear. Can this ticket please be reconsidered? Thanks! > 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] 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_12547524
]
Michael Busch commented on LUCENE-584:
--
{quote}
The patch is backwards compatible,
{quote}
I think that custom Searcher or Searchable implementations won't compile
anymore?
Because the signature of some abstract methods changed, e. g. in Searchable:
{code:java}
@@ -86,13 +86,14 @@
* Called by [EMAIL PROTECTED] Hits}.
*
* Applications should usually call [EMAIL PROTECTED]
Searcher#search(Query)} or
- * [EMAIL PROTECTED] Searcher#search(Query,Filter)} instead.
+ * [EMAIL PROTECTED] Searcher#search(Query,MatchFilter)} instead.
* @throws BooleanQuery.TooManyClauses
*/
- TopDocs search(Weight weight, Filter filter, int n) throws IOException;
+ TopDocs search(Weight weight, MatchFilter filter, int n) throws IOException;
{code}
> 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]
Re: [jira] Created: (LUCENE-1074) Workaround in Searcher.java for gcj bug#15411 no longer needed
On Sat, 1 Dec 2007, Paul Elschot (JIRA) wrote: Workaround in Searcher.java for gcj bug#15411 no longer needed -- Key: LUCENE-1074 URL: https://issues.apache.org/jira/browse/LUCENE-1074 Project: Lucene - Java Issue Type: Improvement Components: Search Reporter: Paul Elschot Priority: Minor This gcj bug has meanwhile been fixed, see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411 This bug is fixed in gcj 4.3 which is not yet released. It might be years before gcj 4.3 (or its successors) are stable and sane on non-linux OSs. Anyhow, with the open sourcing of Java (as openjdk), it's more or less moot now. PyLucene has moved off of gcj by building with jcc [1] instead. Andi.. [1] http://svn.osafoundation.org/pylucene/trunk/jcc/jcc/README - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (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:comment-tabpanel#action_12547496 ] Michael Busch commented on LUCENE-1073: --- Looks great, Mike! 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. -Michael > 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 > > > 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]
[jira] Commented: (LUCENE-1074) Workaround in Searcher.java for gcj bug#15411 no longer needed
[ https://issues.apache.org/jira/browse/LUCENE-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547492 ] Paul Elschot commented on LUCENE-1074: -- The target gcc release for this fix is 4.3.0, which is not yet released. So this will have to wait until gcc 4.3.0 is in use. > Workaround in Searcher.java for gcj bug#15411 no longer needed > -- > > Key: LUCENE-1074 > URL: https://issues.apache.org/jira/browse/LUCENE-1074 > Project: Lucene - Java > Issue Type: Improvement > Components: Search >Reporter: Paul Elschot >Priority: Minor > > This gcj bug has meanwhile been fixed, see: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411 -- 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-1074) Workaround in Searcher.java for gcj bug#15411 no longer needed
[ https://issues.apache.org/jira/browse/LUCENE-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547490 ] Paul Elschot commented on LUCENE-1074: -- See also LUCENE-288 > Workaround in Searcher.java for gcj bug#15411 no longer needed > -- > > Key: LUCENE-1074 > URL: https://issues.apache.org/jira/browse/LUCENE-1074 > Project: Lucene - Java > Issue Type: Improvement > Components: Search >Reporter: Paul Elschot >Priority: Minor > > This gcj bug has meanwhile been fixed, see: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411 -- 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] Created: (LUCENE-1074) Workaround in Searcher.java for gcj bug#15411 no longer needed
Workaround in Searcher.java for gcj bug#15411 no longer needed -- Key: LUCENE-1074 URL: https://issues.apache.org/jira/browse/LUCENE-1074 Project: Lucene - Java Issue Type: Improvement Components: Search Reporter: Paul Elschot Priority: Minor This gcj bug has meanwhile been fixed, see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411 -- 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: Profiling tools
Michael Busch wrote: They offer a free open-source license (http://www.yourkit.com/purchase/index.jsp), however they ask to add a reference to their website to the OS website. Apache frowns on this. They should grant a license to you personally, as an open-source developer, not to the project. The project should be under no obligation to advertise for their company. You could, if you like, provide a link on your personal website, which might be linked to from the project's web site. Doug - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setRAMBufferSizeMB and DEFAULT_RAM_BUFFER_SIZE_MB missing from IndexWriter !
Right, the javadocs are for the nightly build. See the Site Versions section of http://lucene.apache.org/java/docs/index.html for releases. Also, these questions are best asked on [EMAIL PROTECTED] We try to keep java-dev for discussion of development of the actual library. Thanks! -Grant On Dec 1, 2007, at 4:36 AM, Cauvery Developer wrote: oh ! I saw them in the javadoc so I got confused. Thanks, Michael. Regards, Nags On Dec 1, 2007 3:05 PM, Michael McCandless <[EMAIL PROTECTED]> wrote: Hi, These are new APIs, available only in the unreleased trunk (2.3-dev) version of Lucene. They are not present in 2.2. You can pull the nightly trunk build JAR from here: http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/290/artifact/artifacts/ (that's this AM's build). But beware that it could have bugs (it's not yet released)! Mike "Cauvery Developer" <[EMAIL PROTECTED]> wrote: Hi, I am having lucene-core-2.2.0.jar in my CLASSPATH. I do NOT see the method setRAMBufferSizeMB method and the field DEFAULT_RAM_BUFFER_SIZE_MB missing from IndexWriter class. I looked into the source also and sure enough, these items do not exist. Is this a download issue ? Regards, Nags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Grant Ingersoll http://lucene.grantingersoll.com Lucene Helpful Hints: http://wiki.apache.org/lucene-java/BasicsOfPerformance http://wiki.apache.org/lucene-java/LuceneFAQ - 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.take2.patch Attached new patch to fix the intermittant failure. > 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 > > > 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]
[jira] Commented: (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:comment-tabpanel#action_12547413 ] Michael McCandless commented on LUCENE-1073: Woops, the new testcase is failing on windows ... I'll track it down. > 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 > > > 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]
[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.patch Attached patch that has a class (SnapshotDeletionPolicy) plus a unit test (TestSnapshotDeletionPolicy) showing how to use it to do a live backup. I also added a new public method "getFileNames()" to IndexCommitPoint (getting the filenames would otherwise requires package private access to SegmentInfo/s). All tests pass. 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 > > > 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]
[jira] Created: (LUCENE-1073) Add unit test showing how to do a "live backup" of an index
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 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]
Re: Term(String, BufferedReader) constructor ?
"Cauvery Developer" <[EMAIL PROTECTED]> wrote:
> I know, I can I use IndexWriter with createFlag set to false while
> updating. But, this sounds too "comprehensive".
Nomatter what if you are going to update a document, you will have to
open a writer for doing so (or, use a writer you already have open).
> I am trying to implement Lucene for a small set of source files, where
> the entire source is the value for a Field named 'source'. Creating
> the field was easy because there is a constructor for Field using a
> BufferedReader. When there are changes in the source file, I need to
> update the Document in the Index using updateDocument(Term, Document).
> Since, a Term is "...is composed of two elements, the text of the
> word, as a string, and the name of the field that the text occured
> in...", I would have to build the Term with the modified source. But,
> there isn't such a constructor for Term.
The Term that you pass as the first argument to updateDocument must
"identify" the document you want to replace. EG you could add a field
"documentID" that has a unique value per document. You then pass in
Term("documentID", ) to updateDocument. In your case maybe
you could use a canonical fileName or URI to identify the document.
Then, you put your modified source as a Field into the second argument
(document) to the updateDocument method.
Mike
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Term(String, BufferedReader) constructor ?
Hi, If we are able to create a Field using a BufferedReader, why not do the same for the Term as well ? I am trying to implement Lucene for a small set of source files, where the entire source is the value for a Field named 'source'. Creating the field was easy because there is a constructor for Field using a BufferedReader. When there are changes in the source file, I need to update the Document in the Index using updateDocument(Term, Document). Since, a Term is "...is composed of two elements, the text of the word, as a string, and the name of the field that the text occured in...", I would have to build the Term with the modified source. But, there isn't such a constructor for Term. I know, I can I use IndexWriter with createFlag set to false while updating. But, this sounds too "comprehensive". Regards, Nags
Re: Document.getField(field).stringValue() behavior
aaarghhh
You are right, Michael. Apologies for the stupid question.
Regards,
Nags.
On Dec 1, 2007 3:07 PM, Michael McCandless <[EMAIL PROTECTED]>
wrote:
>
> If you call .stringValue() you should get just that string?
>
> (You are now calling .toString()).
>
> Mike
>
> "Cauvery Developer" <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I am working with demo and I am displaying the search results as :
> >
> > Hits ht = is.search(q);
> > for (int i = 0; i <= ht.length(); i++) {
> > Document hitDoc = ht.doc(i);
> > queryResult.add(hitDoc.getField("name").toString() + "~"
> > + hitDoc.getField("date").toString());
> > System.out.println(queryResult) ;
> > }
> >
> > I get the following output :
> >
> >
> stored/uncompressed,indexed~stored/uncompressed,indexed > Nov 30 23:43:50 PST 2007>
> >
> > The result "HWORLD" and "Fri Nov 30 23:43:50 PST 2007" is correct. But,
> I
> > was under the impression that the output would simply be
> >
> > HWORLD~Fri Nov 30 23:43:50 PST 2007
> >
> > Therefore, should the output of Document.getField(field).stringValue()
> > behavior be further parsed to get directly to the term that was added ?
> >
> > Thanks and regards,
> > Nags
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Document.getField(field).stringValue() behavior
If you call .stringValue() you should get just that string?
(You are now calling .toString()).
Mike
"Cauvery Developer" <[EMAIL PROTECTED]> wrote:
> Hi,
> I am working with demo and I am displaying the search results as :
>
> Hits ht = is.search(q);
> for (int i = 0; i <= ht.length(); i++) {
> Document hitDoc = ht.doc(i);
> queryResult.add(hitDoc.getField("name").toString() + "~"
> + hitDoc.getField("date").toString());
> System.out.println(queryResult) ;
> }
>
> I get the following output :
>
> stored/uncompressed,indexed~stored/uncompressed,indexed Nov 30 23:43:50 PST 2007>
>
> The result "HWORLD" and "Fri Nov 30 23:43:50 PST 2007" is correct. But, I
> was under the impression that the output would simply be
>
> HWORLD~Fri Nov 30 23:43:50 PST 2007
>
> Therefore, should the output of Document.getField(field).stringValue()
> behavior be further parsed to get directly to the term that was added ?
>
> Thanks and regards,
> Nags
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: setRAMBufferSizeMB and DEFAULT_RAM_BUFFER_SIZE_MB missing from IndexWriter !
oh ! I saw them in the javadoc so I got confused. Thanks, Michael. Regards, Nags On Dec 1, 2007 3:05 PM, Michael McCandless <[EMAIL PROTECTED]> wrote: > > Hi, > > These are new APIs, available only in the unreleased trunk (2.3-dev) > version > of Lucene. > > They are not present in 2.2. > > You can pull the nightly trunk build JAR from here: > > > http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/290/artifact/artifacts/ > > (that's this AM's build). But beware that it could have bugs (it's not > yet > released)! > > Mike > > "Cauvery Developer" <[EMAIL PROTECTED]> wrote: > > Hi, > > I am having lucene-core-2.2.0.jar in my CLASSPATH. I do NOT see the > > method > > setRAMBufferSizeMB method and the field DEFAULT_RAM_BUFFER_SIZE_MB > > missing > > from IndexWriter class. I looked into the source also and sure enough, > > these > > items do not exist. > > > > Is this a download issue ? > > > > Regards, > > Nags. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: setRAMBufferSizeMB and DEFAULT_RAM_BUFFER_SIZE_MB missing from IndexWriter !
Hi, These are new APIs, available only in the unreleased trunk (2.3-dev) version of Lucene. They are not present in 2.2. You can pull the nightly trunk build JAR from here: http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/290/artifact/artifacts/ (that's this AM's build). But beware that it could have bugs (it's not yet released)! Mike "Cauvery Developer" <[EMAIL PROTECTED]> wrote: > Hi, > I am having lucene-core-2.2.0.jar in my CLASSPATH. I do NOT see the > method > setRAMBufferSizeMB method and the field DEFAULT_RAM_BUFFER_SIZE_MB > missing > from IndexWriter class. I looked into the source also and sure enough, > these > items do not exist. > > Is this a download issue ? > > Regards, > Nags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
setRAMBufferSizeMB and DEFAULT_RAM_BUFFER_SIZE_MB missing from IndexWriter !
Hi, I am having lucene-core-2.2.0.jar in my CLASSPATH. I do NOT see the method setRAMBufferSizeMB method and the field DEFAULT_RAM_BUFFER_SIZE_MB missing from IndexWriter class. I looked into the source also and sure enough, these items do not exist. Is this a download issue ? Regards, Nags.
Document.getField(field).stringValue() behavior
Hi,
I am working with demo and I am displaying the search results as :
Hits ht = is.search(q);
for (int i = 0; i <= ht.length(); i++) {
Document hitDoc = ht.doc(i);
queryResult.add(hitDoc.getField("name").toString() + "~"
+ hitDoc.getField("date").toString());
System.out.println(queryResult) ;
}
I get the following output :
stored/uncompressed,indexed~stored/uncompressed,indexed
The result "HWORLD" and "Fri Nov 30 23:43:50 PST 2007" is correct. But, I
was under the impression that the output would simply be
HWORLD~Fri Nov 30 23:43:50 PST 2007
Therefore, should the output of Document.getField(field).stringValue()
behavior be further parsed to get directly to the term that was added ?
Thanks and regards,
Nags
