Hi,
On Mon, Jun 24, 2013 at 2:47 PM, Mathias Lux <m...@itec.uni-klu.ac.at> wrote:
> Still, I've read that all the BinaryDocValues go directly to memory.
> Am I right with this?
It is true that the current default implementation stores them in
memory. However, disk doc values formats can be configured on a
per-field basis, so you could just write:
Codec codec = new Lucene42Codec() {
final DiskDocValuesFormat diskDVF = new DiskDocValuesFormat();
@Override
public DocValuesFormat getDocValuesFormatForField(String fieldName) {
return diskDVF;
}
}
to store them on disk instead (add conditions on fieldName if you want
to have different behaviors based on the field name).
> I've also tried to change the codec, but I'm stuck with the
> IndexReader. It throws
This is because you defined a new custom codec (with a unique name to
identity it) without registering it in
META-INF/org.apache.lucene.codecs.Codec in your classpath. Note that
the example above doesn't require you to register a different codec
since it is fully compatible with Lucene42Codec and uses the same
name.
> Also I understand that the APIs are still experimental and in no way
> stable. As I'm quite a lazy programmer I'd like to hear you opinion on
> how stable the APIs for BinaryDocValues and Codec might be? :)
I can't predict the future :), but given the time and energy that has
been put into the doc values APIs for the 4.2 release (thanks
Robert!), I'd say that they shouldn't change much in the next months.
--
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
