I have been in email contact over the last week with a customer who followed my detailed, step-by-step Building J2EE Application with Oracle JHeadstart for ADF tutorial. His feedback was that when he tried JHeadstart on a couple of his real-world tables, drilling down from master to detail just hung and never showed the page. Wanting to get to the bottom of the issue, I used our handy Oracle Web Conferencing software to let him show me what was happening. Even better, he granted me remote control of his machine so I could "drive" JDeveloper and check out a few things myself (while he sat back and watched in front of his own PC).All I can say is that I sure wish we had software like Oracle Web Conference back in 1990 when I worked in Oracle Tech Support!
We were able to figure out what was causing the web browser to apparently hang when drilling down to the details. First, a little background. The customer's data model was basic master/detail like classic DEPT and EMP tables, except that in their case, there were 600,000+ "departments" and millions of "employees". Of course, their tables also had more columns, but nothing fancy: a mix of NUMBER, DATE, and VARCHAR types. Like the EMP table, their "detail" table had a self-referencing relationship so that one "detail" could refer to another related detail row via a foreign key. Just like how an EMP row has a MGR field that points to the empno of another manager.
When JHeadstart generated a master/detail set of pages for the customer's data, as it always does when creating a default application structure, it "sniffed" out the associations between the entity objects and created lookups for them. The one of interest was the self-join lookup, so that the end-user can easily pick which employee is their manager from a list of all employees.
The rub lied in the combination of the sheer number of "EMP" rows their data model had (over a million!) and the fact that by default, JHeadstart setup up the lookup to have a displayType of choice. The lookup style of choice renders in the browser as a drop-down list, and like any drop-down list you are familiar with in any web form you've ever filled out, the drop-down list contains the complete list of valid choices to pick from. In this case, the complete list had over a million rows in it, so when ADF UIX was rendering the detail page, that was causing the underlying ADF View Object for the employee lookup to try and fetch all million rows. Had there been enough time and memory to accomplish that, the next "issue" would have been in the sheer bulk of HTML tags that would need to get rendered to the browser to show such a long drop-down list. This would further be complicated by the fact that the display was showing 10 rows in a table, so hypothetically-speaking that HTML page -- effortlessly rendered by ADF UIX's <messageChoice> control -- would be sending ten times a million+ choices down to the browser to render the 10 occurrences of that "employees lookup".
The executive summary was that this is a great example of when a Lookup should be switched to use the LOV style of display instead of the choice style. The LOV style of lookup doesn't query up all the rows for the valid choice, and can be further optimized by unsetting the "Auto-Query" property in the lookup and setting a maximum search hits of some reasonable number for the LOV in the JHeadstart application structure editor.
2:15:18 PM 
|
|
