Michael,
I think I understand your point. I should mention that I'm just a user of
BlockJoin... a year ago, I was doing the same tests you are now and was
just trying to share my observations. :)
I think either rule would be reasonable, but probably prefer that it throws
exception... this helps
Hi Gregory,
Thanks for your reply. In reading it, I realized that one side of my
relational join wasn't that large, and I could bring it in as a couple
of fields to the main document without any penalty, so my need to join
two different document types then goes away.
Thanks! :-)
Glen
On Tue,
You are very likely hitting the issue described here:
https://issues.apache.org/jira/browse/LUCENE-5541
Mike McCandless
http://blog.mikemccandless.com
On Wed, Dec 17, 2014 at 2:03 PM, Shlomit Rosen wrote:
> Hello,
>
> We have a client that is using lucene 3.0.3.
> They are working with NAS st
Hi,
the error message is: “java.io.IOException: No sub-file with id _xv.fnm found”,
produced by CompoundFileReader. This means that, the corresponding compound
file does not contain the missing sile –xv.fnm. Because it should be inside the
CFS file, it is of course not part of the directory.
We our production app uses Lucene 4.2.1. We are going to release a new
version soon and contemplating whether or not to migrate to newer version
of lucene. I see lot of new features were added in later versions but I
want to get an idea of performance improvements?
Hello,
We have a client that is using lucene 3.0.3.
They are working with NAS storage device which recently had permission
issues,
which might have generated some "out of disk space" exceptions during
indexing.
We are uncertain if they also suffered JDK crashes in the past few months,
as we
Hello,
We have a client that is using lucene 3.0.3.
They are working with NAS storage device which recently had permission
issues,
which might have generated some "out of disk space" exceptions during
indexing.
We are uncertain if they also suffered JDK crashes in the past few months,
as we
Hi, Nils,
I don't know Chinese at all... but collation is very important in Japanese
too.
Lucene has org.apache.lucene.collation package that use ICU4J's collators
(you can find "lucene-analyzers-icu-4.10.2.jar" in analysis/icu directory).
http://lucene.apache.org/core/4_10_2/analyzers-icu/index.h
Hi,
is there any implementation for a chinese collator in Lucene. I've seen
that there is a chinese analyzer which uses Hidden Markov Models. But
sorting seems to be an issue on its own and all my googling hasn't led
to any results yet.
I understand that this is not a trivial issue and I've
