Details
-
Improvement
-
Status: Reopened
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
Related entities are often loaded via a separate select operation when an unloaded field is accessed. The select operation for a relationship field structurally (i.e. which tables it joins to or what columns it selects) is invariant at instance level. Only thing that changes across entity instances is the foreign/primary key identifier values used in joining. The major computation cost is paid to analyze to build the select structure by analyzing the mapping metadata of class/field involved. As noted, this computation is invariant for each instance access except the primary/foreign key values involved.
However, the core infrastructure for this frequent operation (because it is carried out whenever a relationship field is loaded for every instance) is not designed for reuse. The select gets constructed every time, the class/field mapping metadata gets analyzed every time, before the select is executed on the database.
What is required to avoid this repeated and unnecessary cost is to reuse a select instance computed for every relationship field only once but binding different parameters on every execution.
The task is non-trivial because of the select abstraction (a highly complex and critical data structure) is not designed with such parameter rebinding in mind.
This issue attempts to remedy that limitation.
Attachments
Issue Links
- incorporates
-
OPENJPA-2111 Optimize column based ResultSet lookup whereever feasible
- Reopened
- is related to
-
OPENJPA-2111 Optimize column based ResultSet lookup whereever feasible
- Reopened
-
OPENJPA-407 Cache SQL (or closer precursors to SQL) more aggressively
- Closed
-
OPENJPA-703 Cache ResultObjectProvider data to improve query performance
- Closed
- relates to
-
OPENJPA-2104 BindParameter is not a valid query parameter as processed in DBDictionary's setUnknown()
- Closed
-
OPENJPA-2121 Determine proper configuration of SQL caches
- Open