[ 
https://issues.apache.org/jira/browse/SOLR-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-1787:
---------------------------

    Fix Version/s:     (was: 4.0)

* There is no indication that anyone is actively working on this issue, so 
removing 4.0 from the fixVersion.
* Assigning in hopes he can assess the current patch to possible revisit the 
issue
                
> 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]

Reply via email to