[
https://issues.apache.org/jira/browse/LUCENE-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618069#action_12618069
]
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...
Proposal:
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: https://issues.apache.org/jira/browse/LUCENE-1340
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
