There are various properties in ADF developers tend to click around. Based on my experience from various ADF projects and what strikes me the most - often some property change is done without actually understanding what it means for application performance, at first comes desire to find solution with any cost. I will give you one example related to CacheResults property for ADF bindings iterator.
By default CacheResults property is set to True:
This means when requests are submitted from ADF UI, current rowset is not re-executed again if rows were fetched already. For example when table is loaded and users selects different rows, during new row selection there is no SQL query executed again:
On opposite, when CacheResults is set to False:
Before every request ADF will re-execute SQL query and fetch previously already fetched rows again and again. Obviously this is not what you want in most of the cases, so be careful with CacheResults property. SQL is executed and rowset is fetched:
In this example - CacheResultsApp.zip, such behavior happens on every row select. I just wanted to show what effect you can get by setting CacheResults property to False.
For my specific case, developer wanted to make sure data is refreshed everytime when there is change in DB. But later this requirement was dropped, however no one remembered to set CacheResults back to default, form complexity was increasing until performance became bad. Ok, but now it is fixed !
By default CacheResults property is set to True:
This means when requests are submitted from ADF UI, current rowset is not re-executed again if rows were fetched already. For example when table is loaded and users selects different rows, during new row selection there is no SQL query executed again:
On opposite, when CacheResults is set to False:
Before every request ADF will re-execute SQL query and fetch previously already fetched rows again and again. Obviously this is not what you want in most of the cases, so be careful with CacheResults property. SQL is executed and rowset is fetched:
In this example - CacheResultsApp.zip, such behavior happens on every row select. I just wanted to show what effect you can get by setting CacheResults property to False.
For my specific case, developer wanted to make sure data is refreshed everytime when there is change in DB. But later this requirement was dropped, however no one remembered to set CacheResults back to default, form complexity was increasing until performance became bad. Ok, but now it is fixed !
No comments:
Post a Comment