On 8/18/05, Doug Cutting <[EMAIL PROTECTED]> wrote:
> Chris D wrote:
> > Well in my case field order is important, but the order of the
> > individual fields isn't. So I can speed up getFields to roughly O(1)
> > by implementing Document as follows.
>
> Have you actually found getFields to be a pe
Chris D wrote:
Well in my case field order is important, but the order of the
individual fields isn't. So I can speed up getFields to roughly O(1)
by implementing Document as follows.
Have you actually found getFields to be a performance bottleneck in your
application? I'd be surprised if it
I'm still having problems finding a clean way of doing this. Currently
my index has
"_" filling in for empty fields in instances
DOC1
FILEID 123
MIME test/html
CONTENTblam blam blam etc.
FILENAME File1
DATE 090909
AUTH _
SESSION11
FILEN
On 8/11/05, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
>
> > So I've decided I'm going to simply have empty fields, and that
> > brought up several other questions.
> >
> > First, is there a limit on the number of fields per document?
>
> I don't think so.
>
> > Secondly why are fields in Docum
> So I've decided I'm going to simply have empty fields, and that
> brought up several other questions.
>
> First, is there a limit on the number of fields per document?
I don't think so.
> Secondly why are fields in Document implemented with a Vector instead
> of a HashSet or similar? Wouldn't
So I've decided I'm going to simply have empty fields, and that
brought up several other questions.
First, is there a limit on the number of fields per document?
Secondly why are fields in Document implemented with a Vector instead
of a HashSet or similar? Wouldn't retrieval be faster without
ite
I'm adding files to an index over time, so after some time I'm likely
to see the same file more than once. I would like to be able to search
for the information about that particular instance of the file
(Filename, date etc) For instance I index File1 and then File2 (which
are identical) at differe
