lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll (JIRA)" <>
Subject [jira] Commented: (LUCENE-1340) Make it posible not to include TF information in index
Date Tue, 29 Jul 2008 22:33:31 GMT


Grant Ingersoll commented on LUCENE-1340:

Yeah, it's one of my biggest regrets in Lucene (yes, I am responsible for it), yet I firmly
believe there is a way to do interfaces and abstracts in a proper way in Java.

We could make LazyField extend AbstractField, I think, but it's not clear, as there are some
differences between the two, mostly around construction.  I'd have to go back and review again.

That being said, I still think if there is one place where we should allow breaking the back
compat. contract, it is Fieldable!  For every rule, there is an exception, right?  I thinnk
we could, w/ sufficient warning, tell people that we are changing the interface.  I am willing
to bet that the number of people that would be effected by that would be less than 10.

So, please don't give up on this patch.  I am totally 100% for it.  I think it makes total
sense to do.  

Another option is to speed up going towards 3.0

> Make it posible not to include TF information in index
> ------------------------------------------------------
>                 Key: LUCENE-1340
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Index
>            Reporter: Eks Dev
>            Priority: Minor
>         Attachments: LUCENE-1340.patch, LUCENE-1340.patch, LUCENE-1340.patch, LUCENE-1340.patch,
LUCENE-1340.patch, LUCENE-1340.patch, LUCENE-1340.patch
>   Original Estimate: 24h
>  Remaining Estimate: 24h
> Term Frequency is typically not needed  for all fields, some CPU (reading one VInt less
and one X>>>1...) and IO can be spared by making pure boolen fields possible in Lucene.
This topic has already been discussed and accepted as a part of Flexible Indexing... This
issue tries to push things a bit faster forward as I have some concrete customer demands.
> benefits can be expected for fields that are typical candidates for Filters, enumerations,
user rights, IDs or very short "texts", phone  numbers, zip codes, names...
> Status: just passed standard test (compatibility), commited for early review, I have
not tried new feature, missing some asserts and one two unit tests
> Complexity: simpler than expected
> can be used via omitTf() (who used omitNorms() will know where to find it :)  

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