[
https://issues.apache.org/jira/browse/LUCENE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oswaldo Dantas updated LUCENE-2394:
-----------------------------------
Attachment: factoriesPatch.patch
Attaching factory suggestion (patch for changes to
https://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_9_2) focusing in
cache, being used in specifically in FieldCacheImpl and TermInfosReader to
exemplify.
> Factories for cache creation
> ----------------------------
>
> Key: LUCENE-2394
> URL: https://issues.apache.org/jira/browse/LUCENE-2394
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Oswaldo Dantas
> Fix For: 2.9.3, 3.0.2
>
> Attachments: factoriesPatch.patch
>
>
> Hello all,
> I've seen the LUCENE-831 (Complete overhaul of FieldCache API/Implementation)
> targeted for version 3.1 and I think that maybe, before this overhaul, it
> would be good to have a more cirurgical change, that would need smaller
> effort in new unit tests, without behavior changes and almost no performance
> impact.
> One way to achieve that is inserting strategically positioned calls to a
> factory structure that would allow every already developed code to continue
> working without changes, at the same time giving the opportunity to put
> alternative factories to work.
> Focusing on the cache idea (not specifically the FieldCache, that has it's
> own specific responsabilities, but in the key/value structure that will
> ultimately hold the cached objects) i've done the small change contained in
> the patch I'm attaching to this.
> It has default implementations that encapsulate what was being originally
> used in FieldCache, so all current test cases passes, and creates the
> possibility to create a EHCacheFactory or InfinispanCacheFactory, or even
> MyOwnCachingStructureFactory.
> With this, it would be easy to take advantage of the features provided by
> this kind of project in a uniform way and rapidly allowing new possibilities
> in scalability and tuning.
> The code in the patch is small (16kb file is small if compared to the
> hundreds of kbs in other patchs) and even though it doesn't have javadoc
> right now (sorry) I hope it can be easly understood. So, if Lucene
> maintainers see that this contribution could be used (in a 2.9.n+1 and
> 3.0.n+1 and maybe influencing future versions) we could put some more effort
> in it, documenting, adding necessary unit tests and maybe contributing other
> factory implementations.
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
