lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-2380) Add FieldCache.getTermBytes, to load term data as byte[]
Date Tue, 18 May 2010 18:06:45 GMT


Michael McCandless commented on LUCENE-2380:

bq. Ahhh, fun stuff! I'm packing for Prague though - prob won't be able to look at this for
a week.

OK no prob... have fun!

bq. 1 or 2? a max len of 2**15? (I know... a term bigger than 32K would be horrible, but so
are limits that aren't necessary)

Indexer already has this limit, during indexing (these large terms are skipped).

bq. re: returning null if an ord of 0 is passed to get(int ord, BytesRef ret): do we need
to do this? We could record 0 as zero length in the FieldCache and hence avoid the special-case
code. We could require the user to check for 0 if they care to know the difference between
zero length and missing.

I would love to return empty string (not null) if ord 0 comes in, and require caller to specifically
handle ord 0 if they need to differentiate... I had started down that path but got spooked
by it :)  I think we can revisit it, but maybe separately.

> Add FieldCache.getTermBytes, to load term data as byte[]
> --------------------------------------------------------
>                 Key: LUCENE-2380
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.0
>         Attachments: LUCENE-2380.patch
> With flex, a term is now an opaque byte[] (typically, utf8 encoded unicode string, but
not necessarily), so we need to push this up the search stack.
> FieldCache now has getStrings and getStringIndex; we need corresponding methods to load
terms as native byte[], since in general they may not be representable as String.  This should
be quite a bit more RAM efficient too, for US ascii content since each character would then
use 1 byte not 2.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message