openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Vorburger (JIRA)" <>
Subject [jira] Commented: (OPENJPA-701) Ability for fine-grained configuration of exclusion of foreign key columns in FetchPlan
Date Mon, 25 Aug 2008 09:33:44 GMT


Michael Vorburger commented on OPENJPA-701:

PS: This issue was created based on a discussion on, see;
quote Pinaki: "Once A has lots of to-one relations, it is a valid concern that A will store
a lot of FK values in intermediate storage (perhaps without ever using them), but just wanted
to underline that there is no significant performance penalty in such cases as the values
are read from an existing row."

> Ability for fine-grained configuration of exclusion of foreign key columns in FetchPlan
> ---------------------------------------------------------------------------------------
>                 Key: OPENJPA-701
>                 URL:
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: jdbc, sql
>    Affects Versions: 1.1.0
>            Reporter: Michael Vorburger
>            Priority: Minor
> Currently (v1.1.0), "Even when a direct relation is not eagerly fetched, OpenJPA selects
the foreign key columns and caches the values. This way when you do traverse the relation,
OpenJPA can often find the related object in its cache, or at least avoid joins when loading
the related object from the database. " (
> In a domain model with "wide" classes that have lot's of associations = foreign key columns
on some tables, under a use case where you KNOW that you will not traverse some relations
(because you know you'll only access 1-2 of many, configured by some upper layer, other getters
may not even be available to end-code), it would be nice if the FetchPlan API was extended
to allow for more fine-grained configuration of exclusion / inclusion of foreign key columns.
> Design proposal, just an idea, could certainly be implemented differently: For backward
compatibility, the current behaviour would likely have to stay as is. In addition however,
a new method named e.g. FetchPlan.doNotIncludeAllForeignKeyColumns() [or a more suitable shorter
name... :)] would cause the plan NOT to select any foreign key column by default. Only FK
columns that were explicitly added via addField() would then be selected; if no fields in
the referenced class are specified via another addField, then only the originating PK column
would be included, if any field in the referenced class are also specified, then the JOIN
would happen (as today - or would this simple API not suffice?). -- Minor: Ideally, an addField()
for the association and another addField() for only the ID/PK attribute of the related class
should not lead to a SQL JOIN either, as the ID/PK is in the original table of course, even
if in the object model it's an attribute of the related class.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message