2 of 2 people found this helpful
Currently, Table Lookup will support asynchronous calls if it uses any input that support asynchronous calls (e.g. a PIPoint DR). When we introduced async calls in AFSDK 2.8, we decided to support async only when there was some meaningful aspect of the call that could be done asynchronously, leaving it to users to decide how fallback should work (e.g. either making a synchrounous call or running on a background task). You can check:
to see if the asynchronous method is supported and handle fallback as appropriate for you application if it is not.
We have had feedback from some users that needing to handle this manually is cumbersome so there are a couple options:
- Add support for native async calls with Table Lookup (this would involve adding asynchronous methods to acquire the table from the AF Server).
- Allow the application developer to specify how to handle attributes that don't have native async support and let async calls work for any attribute.
These are not mutually exclusive but I'm interested in your opinion as to which is more important.
I fully understand your reasoning behind your decisions. If there was no native async call for table lookup, I as an application developer would like to decide wether I want to run it in an background task or use it synchronously.
Personally I would like to see option 1 implemented, as in our application we sometimes have 200+ Attributes with a table lookup datareference and wrapping all those calls in a background task creates way too much overhead.
May I ask you another question related to table lookups? The first access of the AF Table Lookup after application startup takes ~30 seconds, subsequent calls happen immediately. I assume this is related tocaching. Is there a way to make AF cache the table independent from any calls? So that when I first start up my application, the table is already cached and I can access data instantly? (note that I set cache Interval to 1 day)
The Table Lookup DR asks the SDK for the table - the caching of tables is handled by the SDK. So if you want to pre-load the tables to speed data access, you could fetch them proactively from your AFDatabase. There is a method available to load tables in bulk which might be of use:
Alright, thank you very much David!