[
https://issues.apache.org/jira/browse/LUCENE-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722862#action_12722862
]
Michael McCandless commented on LUCENE-1701:
--------------------------------------------
bq. My point was that strict back-compat prevents people from donating work
which is not yet finalized. They either lose comfortable volatility of private
code, or have to maintain two versions of it - private and Lucene.
That's a good point, though if it's contrib and you're a contrib committer it
lessens the challenge, but the challenge is still there....
bq. I vote it for the most frustrating (in terms of adopting your custom code)
and most useful change of 2.9
No pain no gain?
bq. Do we still need to add complexity for minor performance gains?
The problem is I've seen fsync take a ridiculous amount of time; it's not very
predictable. So I think we do need some way to not put fsync between the
changes to the index and the ability to search those changes.
{quote}
> And this integration lets us take it a step further with LUCENE-1313,
> where recently created segments can remain in RAM and be shared with
> the reader.
RAMDirectory?
{quote}
Exactly; that's what LUCENE-1313 is doing (flush new segments to a RAMDir).
bq. This was yet another praise to per-segment collection and an example of how
this approach can be extended on your custom stuff (like filtercache).
OK.
> Add NumericField and NumericSortField, make plain text numeric parsers public
> in FieldCache, move trie parsers to FieldCache
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1701
> URL: https://issues.apache.org/jira/browse/LUCENE-1701
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Index, Search
> Affects Versions: 2.9
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1701-test-tag-special.patch, LUCENE-1701.patch,
> LUCENE-1701.patch, LUCENE-1701.patch, LUCENE-1701.patch, LUCENE-1701.patch,
> LUCENE-1701.patch, NumericField.java
>
>
> In discussions about LUCENE-1673, Mike & me wanted to add a new NumericField
> to o.a.l.document specific for easy indexing. An alternative would be to add
> a NumericUtils.newXxxField() factory, that creates a preconfigured Field
> instance with norms and tf off, optionally a stored text (LUCENE-1699) and
> the TokenStream already initialized. On the other hand
> NumericUtils.newXxxSortField could be moved to NumericSortField.
> I and Yonik tend to use the factory for both, Mike tends to create the new
> classes.
> Also the parsers for string-formatted numerics are not public in FieldCache.
> As the new SortField API (LUCENE-1478) makes it possible to support a parser
> in SortField instantiation, it would be good to have the static parsers in
> FieldCache public available. SortField would init its member variable to them
> (instead of NULL), so making code a lot easier (FieldComparator has this ugly
> null checks when retrieving values from the cache).
> Moving the Trie parsers also as static instances into FieldCache would make
> the code cleaner and we would be able to hide the "hack"
> StopFillCacheException by making it private to FieldCache (currently its
> public because NumericUtils is in o.a.l.util).
--
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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
