[
https://issues.apache.org/jira/browse/SOLR-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446021#comment-13446021
]
James Dyer commented on SOLR-1787:
----------------------------------
SOLR-2382 added support for pluggable cache implementations, which might be
able to better support Michael's 2 use-cases for this, making this feature less
needed. Also, the patch is very much out of date and lacks unit tests. Given
an apparent lack of interest on this one, I would make it "won't fix" unless
anyone objects.
> Add ability to configure behavior of cache miss to CachedSqlEntityProcessor
> ---------------------------------------------------------------------------
>
> Key: SOLR-1787
> URL: https://issues.apache.org/jira/browse/SOLR-1787
> Project: Solr
> Issue Type: Improvement
> Components: contrib - DataImportHandler
> Affects Versions: 1.5
> Environment: jdk 1.6.x, windows xp, tomcat 6.x
> Reporter: Michael Henson
> Assignee: Noble Paul
> Priority: Minor
> Labels: dih
> Attachments: solr-1787.patch
>
>
> The CachedSqlEntityProcessor currently builds a cache of rows it sees as it
> goes, so later requests for that same key can be served from data that has
> already been fetched. The primary query could be written to fetch all
> possible rows, which would then be set into the cache on the first request
> for a row. In that case the database would only receive another query when
> there is a cache miss. However, the query it would execute is the one that
> pulls all rows, negating any performance gain.
> This patch adds the ability to configure behavior on cache miss with the
> "onCacheMiss" attribute on an "entity" tag in the data-config.xml file. The
> current behavior is the default, corresponding to the setting
> onCacheMiss="fill". Any other value explicitly given for onCacheMiss will
> cause cache misses to be ignored - no query will be made to the db to fulfill
> them.
> I've encountered two cases where this capability is useful:
> 1. Relatively small datasets, such as category id -> category name mappings,
> which will not change during the course of indexing.
> 2. Queries which are heavy on db resources per-query, particularly if the
> query for an individual record is slow, and can't be fixed easily on the db
> side for whatever reason.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
