Erik Hatcher writes:
> > Your changes look great in general, though I find some issues:
> >
> > 1) 'stop OR stop AND stop' where stop is a stopword gives a parse
> > error:
> > Encountered "" at line 1, column 0.
> > Was expecting one of:
> > ...
> > ...
>
> I think you must have tried this
Hi Mark, partially, yes. But I suppose for Document has to be further
subclassed so that the other non-initialized fields can be obtained as well, or
perhaps an additional method to init the remaining fields from a partially
initialized Doc?
Thanks for responding..
k
On Mon, 07 Mar 2005 21:00:
Morus - thanks for your quick checks. More below
On Mar 7, 2005, at 3:32 PM, Morus Walter wrote:
I had a quick look at the new QP. I didn't look at the code yet, but I
redid my patch at the weekend for the current code, and I found it
quite
ugly ;-) I didn't finish it completely, so I didn't
Did you mean this?
http://marc.theaimsgroup.com/?l=lucene-user&m=108525376821114&w=2
Kelvin Tan wrote:
This is a bump post...
I'm wondering if there's any code (contributed, bugzilla, core or otherwise)
that provides document lazy-loading functionality, i.e. only eager-initialize
specific fields
Hi Erik,
> I've been making local changes to QueryParser to fix the operator
> precedence issues (i.e. currently A AND B OR C AND D parses to +A +B +C
> +D).
>
I had a quick look at the new QP. I didn't look at the code yet, but I
redid my patch at the weekend for the current code, and I found
This is a bump post...
I'm wondering if there's any code (contributed, bugzilla, core or otherwise)
that provides document lazy-loading functionality, i.e. only eager-initialize
specific fields, or load fields on-demand.
Thanks,
k
On Thu, 3 Mar 2005 13:55:00 +0100, Kelvin Tan wrote:
> Is this
Hi all,
We index our documents in the following way:
doc = new Document();
// mailid
doc.add(Field.UnIndexed("mid",mid));
//body
doc.add(Field.UnStored("body", textb));
mid is a unique identifier, and body contains long pieces of text to be indexed.
On Mar 7, 2005, at 11:35 AM, Daniel Naber wrote:
On Monday 07 March 2005 11:30, Erik Hatcher wrote:
- Deprecate our current QueryParser and refer users to the new
PrecedenceQueryParser.
I'd consider fixing the precedence a bugfix, so I' prefer to rename
QueryParser to "OldQueryParser" or so
On Monday 07 March 2005 11:30, Erik Hatcher wrote:
> - Deprecate our current QueryParser and refer users to the new
> PrecedenceQueryParser.
I'd consider fixing the precedence a bugfix, so I' prefer to rename
QueryParser to "OldQueryParser" or so and make the new one "QueryParser".
Rega
I've gone ahead and committed my PrecedenceQueryParser. I cloned
TestQueryParser into TestPrecedenceQueryParser and fixed the one item
mentioned below.
Please give this new PrecedenceQueryParser a try and report back any
issues you find with it. I'm still on the steep side of the JavaCC
lear
Hello;
I posted a question about ZIPS a while back. I thought I would post the
solution I arrived at.
Below is how I ended up handling ZIP files. If a situation occurs where
there are ZIPS inside of ZIPS I ignore the embedded ZIP. If requests come in
to handle this situation, I think I will have
Argh, okay. Thank you very much.
On Mon, 7 Mar 2005, Mario Ivankovits wrote:
Joseph B. Ottinger wrote:
Is there a way, after IndexWriter.addDocument(), to determine what the
document's resulting id is? addDocument() has no return type; I could run a
search, but the search might not be accurate if
Joseph B. Ottinger wrote:
Is there a way, after IndexWriter.addDocument(), to determine what the
document's resulting id is? addDocument() has no return type; I could
run a search, but the search might not be accurate if the document
added is only slightly different than another document.
Would
Is there a way, after IndexWriter.addDocument(), to determine what the
document's resulting id is? addDocument() has no return type; I could run
a search, but the search might not be accurate if the document added is
only slightly different than another document.
Would an external id be necessa
I've been making local changes to QueryParser to fix the operator
precedence issues (i.e. currently A AND B OR C AND D parses to +A +B +C
+D).
I've gotten every TestQueryParser test to pass without modification
including this new one:
public void testPrecedence() throws Exception {
Query
15 matches
Mail list logo
