This content has been marked as final. Show 5 replies
I assume your lookup manager is like our LookupManagers, implementing ILookupManager and is retrieved via the LookupService. If so, then it is up to to the implementation in the code to not cache the list of returned items. I believe that if you always have the AllLookupItems method pull the data from the DB, then it could work. But there is a chance that another caching layer is happening since you are using this in an extended attribute. What does your code do? Is it caching the list of results?1 person found this helpful
The lookup manager class does implement ILookupManager with a factory method implementing ILookupManagerFactory to create it. The code queries the SCRM company table in order to return the current list of companies for selection. The values returned by GetLookupItemByKey when the attribute is displayed are being retrieved once and cached via the code, now that you've suggested that. That explains the attribute display values not updating, but I've tested this with and without using the cache and it doesn't seem to affect the lookup dialog box contents.
The AllLookupItems method runs a DataManager query whenever it's called, and doesn't use a cache. I found that this is being called the first time the lookup dialog is opened for the attribute after an IIS reset, but not for subsequent openings of the dialog. Is this due to the potential additional caching layer you mentioned?
Any further input on this, or is a daily reset of IIS the only way to force this to update?
We are looking into it. Stay tuned.
The application caches custom lookup manager values within our extended attribute service.
You can schedule a cache flush request for "Extended Attributes / Custom Sections" cache group that I think will flush your cached values.