[ https://issues.apache.org/jira/browse/SOLR-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul reassigned SOLR-1787: -------------------------------- Assignee: Noble Paul > CachedSqlEntityProcessor pre-warmed cache use case > -------------------------------------------------- > > 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 > Fix For: 1.5 > > 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. - You can reply to this email to add a comment to the issue online.