Sorry about that. The areas were related to Lucene specific features in terms
of the indexing and parsing. The problem lied with the dataset tied to the
entities.
I'll be sure to state that before hand in the future.
Thanks.
Erick Erickson wrote:
>
> u, that would have been a really usefu
The Java version of extended VTD-XmL is released and available for download.
This version supports 256 GB max file sizes and memory mapped capabilities.
The updated documentation is also available for download. In short, you can
basically do full XPath query on documents that are bigger than memor
Dislaimer: I don't really understand your goal, or JSON, so i'm only
addressing the part of your question i do understand, but i may be
overlooking something obvious that could help you...
: Which would get expanded to the obvious "name.first:Paul
: name.last:Paul". I was planning on just doin
: I want to be able to get the number of tokens in a certain field.
:
: Is this possible? Where is this sort of information stored?
generally this info isn't actually recorded in the index -- it's used to
compute a fieldNorm, and that is recorded.
You might be able to get this by turning on Te
u, that would have been a really useful bit of information in
your original post
Erick
On Tue, Oct 21, 2008 at 4:24 PM, samd <[EMAIL PROTECTED]> wrote:
>
> I'm using Hibernate Search and now looking I think it is more related to
> this. Hibernate Search indexing and parsing is based on L
I'm using Hibernate Search and now looking I think it is more related to
this. Hibernate Search indexing and parsing is based on Lucene but it is
tied to the entities unless you use projections.
I guess I'll need to go down this road for now.
Thanks
--
View this message in context:
http://www.
this can absolutely be done, so don't go off the deep end .
Could we see the index snippet and the search snippet when
you tried with StandardAnalyzer?
Etick
On Tue, Oct 21, 2008 at 2:59 PM, samd <[EMAIL PROTECTED]> wrote:
>
> I have tried doing both the indexing and parsing with the same parse
I have tried doing both the indexing and parsing with the same parser being
the StandardAnalyzer. I'm seeing the same result.
I'm going to have to search based off the documentid by the looks of it if I
can't do an exact search on a single term.
Erick Erickson wrote:
>
> I'd really recommend
You say the timestamp sort is taking lots of RAM, which leads
me to ask "what resolution are you using and do you need
that great a resolution"?
As I understand it, sorting is sensitive to the number of unique
terms, so if you're storing millisecond timestamps you have a
whole lot more terms than
Hello,
We have implemented a research module for lucene using BM25 and our
structured version of BM25 as ranking functions and a couple of
state-of-art query expansion algoritms.
This implementation is quite different to other query expansion
modules for Lucene that are available in the web.
We
Hello all,
I need to maintain multiple db and i don't want to sort on datetime as it is
taking huge RAM. I want to sort on indexed order. Using Multisearcher or
ParallelMultiSearcher will maintain the index order. If it does then i don't
need to merge the indexDB.
Regards
Ganesh
Send inst
I'd really recommend you get a copy of Luke and examine what
your index really contains. You say:
<<>>
StandardAnalyzer? When? If you *index* with SnowballAnalyzer, your
token would (probably) be "foo" rather than "foo1". So at *query* time,
it wouldn't make any difference whether you used Standa
The Snowball Analyzer was chosen since there are cases where the stemming is
desired. This is one case where it is not although the same results are
produced with the Standard Analyzer. If this doesn't work I guess I'll
probably need to try to programmatically provide an additional field to the
se
13 matches
Mail list logo
