lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eks Dev (JIRA)" <>
Subject [jira] Commented: (LUCENE-1340) Make it posible not to include TF information in index
Date Wed, 30 Jul 2008 05:49:31 GMT


Eks Dev commented on LUCENE-1340:

that sound like consensus :) Great!

in that case LUCENE-1219 can be reworked slightly to avoid instanceoff (less code). Also it
opens a way to pass reference to byte[] for retrieving stored fields out of lucene and communicating
length back to caller (now we new byte[] every time we fetch stored field) 

bq. 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. 

no need to regret Grant, if you do nothing you make no mistakes... Interfaces are ok, as long
as you can tell what they are going to be doing in next 5 years... this forces you to design
"for the future"... something we cannot afford in so popular and complex libraries like lucene
at places like Field. Abstract* is equally good design-abstraction...  

We could live with a statement "Fieldable changes are allowed from now, it is deprecated and
will be  probably removed in 3.0" , it causes just a tiny bit of work in case someone is really
implementing it (adding new methods to Fieldable like omitTf() costs you max 5 minutes work
to change your implementing class to implement it!).

from 3.0 on, I could very well live without it, until then, we cause 5 minutes work for people
that implement Fieldable on their own and want to stay up to date with the trunk.  It is fair
 deal for everyone and lucene moves forward... 



> 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