This post is about ADF BC LOV. I will describe how you could optimize bulk insert of new rows into VO, when some of the attributes are assigned with LOVs. By default ADF would validate new row attribute value through LOV (LOV Validation and Programmatic Row Insert Performance) for each new row. This will lead to bad performance, especially if you insert a set of new rows programmatically - there will be multiple SQL queries executed to check if LOV attribute value exists.
My colleague found a way to bypass LOV validation when new rows are created programmatically by calling ADF BC API createAndInitRow instead of createRow.
Sample application - LOVValidationBulkInsertApp.zip is developed with LOV for JobId attribute:
We should see first how it works to insert row with LOV attribute by calling createRow ADF BC API:
With SQL log enabled, you should see SQL query executed for LOV, when custom method from above is called:
Now change createRow method to createAndInitRow, to see the difference:
This time no LOV SQL query (for Job Id attribute) executed during new row creation:
My colleague found a way to bypass LOV validation when new rows are created programmatically by calling ADF BC API createAndInitRow instead of createRow.
Sample application - LOVValidationBulkInsertApp.zip is developed with LOV for JobId attribute:
We should see first how it works to insert row with LOV attribute by calling createRow ADF BC API:
With SQL log enabled, you should see SQL query executed for LOV, when custom method from above is called:
Now change createRow method to createAndInitRow, to see the difference:
This time no LOV SQL query (for Job Id attribute) executed during new row creation:
Can I use createAndInitRow to skip method validation in EO. Please suggest. If yes, How to handle update case. Please suggest
ReplyDeletethanks a ton, Andrejus!
ReplyDelete