[SOLR-6439] Delta Import does not work if cacheImpl attribute is set on entity

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Won't Fix
• Affects Version/s: 4.9
• Fix Version/s: 6.0
• Component/s: contrib - DataImportHandler
• Assignee: Unassigned
• Reporter: Ravikanth Gangarapu
• Created: 27/Aug/14 04:15
• Updated: 29/Aug/20 20:28
• Resolved: 29/Aug/20 20:28

Description

Solr Delta Import process will fail while running deltaQuery and parentDeltaQuery queries throwing Class cast exceptions if cacheImpl attribute is set on entity. The problem is if cacheImpl is set, then EntityProcessorBase's initCache will instantiate DIHCacheSupport instance and during getNext() method, it will try to load from cacheLookUp based on cacheForeignKey. But, when in FIND_DELTA stage, we don't know the parent and we trying to find the parent. So, there is no reason to put/get the query results in cache as potentially the same deltaQuery is not run again. So, please fix the if condition to just go thru with rowiterator and get the deltaQuery results instead of the else condition with cache lookup etc. If caching must be utilized for deltaQuery and parentDeltaQuery also, then change the DIHCacheSupport class to peform a simple cache lookup rather than id cache lookup if its a find_delta process.

Another issue around the same feature is that, in solr community people suggest to make the cacheImpl attribute value a variable so that variable resolves to a real cache implementation class in full-import and on delta-import, we can make it empty ( e.g. controlling cache class name via custom request parameter). But, EntityProcessorBase doesn't check if cacheImpl class name is a non-empty string, just checks null and based on non-null value will try to instantiate an empty string class name and fails.

I am providing a patch. Please put them in next release as they are really simple fixes.

Issue Links

• is superceded by: SOLR-14783 Remove DIH from 9.0