I have a custom lookup manager which is used on qualitative lookup attributes to provide a list of choices based upon a SQL query of other PLM objects. It works correctly in that it shows the type of choices expected in the pop-up selection dialog, and populates the attribute value correctly when the user selects a choice and later when they view the specification outside of edit mode. The issue I'm running into is that even if the result set from the lookup's query changes, the choices available in the pop-up dialog (and those already tied to attribute values) do not reflect the updated values since they are apparently cached after the first use of the lookup (call to AllLookupItems). The new values will appear after an IIS reset.
Is there a way to force the cache for this lookup to refresh itself each time the pop-up dialog is opened, and also when PLM retrieves the values for existing attributes using the custom lookup when the spec is viewed? Potential performance impact from database hits are understood, just wondering if this is a possibility.
I appreciate any advice, thanks.
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?
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?
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.