[
https://issues.apache.org/jira/browse/SOLR-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604119#comment-13604119
]
Sudheer Prem edited comment on SOLR-3857 at 3/16/13 5:46 AM:
-------------------------------------------------------------
If my understanding is correct, those who are using this approach to use
'simple' cache query for the child entity, note one important thing:
This approach checks only the current query with the previous query, NOT with
all previous queries.
As the caching is happening after the query initialization is done and the
query execution is happening during the initialization, if any previously
cached query needs to be used again, the query will get executed again and the
old cache will get replaced with new cache. This will have negative performance
impact as the same query gets executed and replace the cache multiple times.
For example: If the child query is: "select * from table where
param={parent.field1}" and the parent.field1 are (1,2,1,2,1,2,1,2), the child
query will get executed for all ${parent.field1} values!
To avoid this, make sure that, the query for the parent entity is ORDERED using
the parameter/parameters used in the query for the child entity.
If ordering is impossible due to performance reasons,there are two ways to
handle this scenario:
1. All queries after the token replacement should be cached (using an
implementation of Set?) in the SqlEntityProcessor class
OR
2. Add a new API in the DIHCacheSupport to tell whether the cache exists for a
query or not
Then perform the check before the query initialization.
was (Author: sudheerprem):
Those who are using this approach to use 'simple' cache query for the child
entity, note one important thing:
This approach checks only the current query with the previous query, NOT with
all previous queries.
As the caching is happening after the query initialization is done and the
query execution is happening during the initialization, if any previously
cached query needs to be used again, the query will get executed again and the
old cache will get replaced with new cache. This will have negative performance
impact as the same query gets executed and replace the cache multiple times.
For example: If the child query is: "select * from table where
param={parent.field1}" and the parent.field1 are (1,2,1,2,1,2,1,2), the child
query will get executed for all ${parent.field1} values!
To avoid this, make sure that, the query for the parent entity is ORDERED using
the parameter/parameters used in the query for the child entity.
If ordering is impossible due to performance reasons,there are two ways to
handle this scenario:
1. All queries after the token replacement should be cached (using an
implementation of Set?) in the SqlEntityProcessor class
OR
2. Add a new API in the DIHCacheSupport to tell whether the cache exists for a
query or not
Then perform the check before the query initialization.
> DIH: SqlEntityProcessor with "simple" cache broken
> --------------------------------------------------
>
> Key: SOLR-3857
> URL: https://issues.apache.org/jira/browse/SOLR-3857
> Project: Solr
> Issue Type: Bug
> Affects Versions: 3.6.1, 4.0-BETA
> Reporter: James Dyer
> Attachments: SOLR-3857.patch
>
>
> The wiki describes a usage of CachedSqlEntityProcessor like this:
> {code:xml}
> <entity name="y" query="select * from y where xid=${x.id}"
> processor="CachedSqlEntityProcessor">
> {code}
> This creates what the code refers as a "simple" cache. Rather than build the
> entire cache up-front, the cache is built on-the-go. I think this has
> limited use cases but it would be nice to preserve the feature if possible.
> Unfortunately this was not included in any (effective) unit tests, and
> SOLR-2382 entirely broke the functionality for 3.6/4.0-alpha+ . At a first
> glance, the fix may not be entirely straightforward.
> This was found while writing tests for SOLR-3856.
--
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]
