You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Sandeep Shrivastava (JIRA)" <ji...@apache.org> on 2008/04/18 17:30:21 UTC
[jira] Created: (OPENJPA-576) Recursively embedded entities
generate an extra and reduntant SQL call to the database.
Recursively embedded entities generate an extra and reduntant SQL call to the database.
---------------------------------------------------------------------------------------
Key: OPENJPA-576
URL: https://issues.apache.org/jira/browse/OPENJPA-576
Project: OpenJPA
Issue Type: Bug
Components: jdbc
Environment: OpenJPA 1.1.0-SNAPSHOT
version id: openjpa-1.1.0-SNAPSHOT-r422266:647033
Apache svn revision: 422266:647033
os.name: Windows XP
os.version: 5.1
os.arch: x86
java.version: 1.6.0_05
java.vendor: BEA Systems, Inc.
Reporter: Sandeep Shrivastava
Fix For: 1.1.0
Consider the following persistent class model. The accessor methods are removed for the sake of brevity.
public class EmbeddedOwnerPC {
private int id1;
private int id2;
private String stringField;
private EmbeddedPC embedded;
private ComplexEmbeddedPC complexEmbedded;
}
public class EmbeddedPC {
private int intField;
private String stringField;
}
public class ComplexEmbeddedPC extends RecursivelyEmbeddedPC {
private String stringField;
private EmbeddedOwnerPC ownerField;
private Set stringSet = new HashSet();
}
public class RecursivelyEmbeddedPC {
private EmbeddedPC embedded;
}
When trying to retrieve the EmbeddedOwner entity with a given fetch plan that includes the complexEmbedded and the embedded fields in the RecursivelyEmbeddedPC class it generate the following 2 SQL statements to load the entity.
SELECT t0.TYP, t0.VERSN, t0.EMBEDDED_NULL, t0.ID1, t0.ID2, t0.INTFIELD1,
t0.STRINGFIELD3, t0.STRINGFIELD FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ? FOR UPDATE
SELECT t0.ID1, t0.ID2 FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ?
FOR UPDATE
The second call is reduntant and not needed. The fix is to the EmbedFieldStrategy class load method to ensure that all fields that are required to be loaded as per the fetch plan and included from the result set and ONLY when this is not true then generate the extra call otherwise return a hollow embedded entity. In the above test case the extra call was generated to get the stringSet field which was not specified in the fetch plan but the call is made out nevertheless which just selects the primary keys with the same where clause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-576) Recursively embedded entities
generate an extra and reduntant SQL call to the database.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Linskey resolved OPENJPA-576.
-------------------------------------
Resolution: Fixed
> Recursively embedded entities generate an extra and reduntant SQL call to the database.
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-576
> URL: https://issues.apache.org/jira/browse/OPENJPA-576
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Environment: OpenJPA 1.1.0-SNAPSHOT
> version id: openjpa-1.1.0-SNAPSHOT-r422266:647033
> Apache svn revision: 422266:647033
> os.name: Windows XP
> os.version: 5.1
> os.arch: x86
> java.version: 1.6.0_05
> java.vendor: BEA Systems, Inc.
> Reporter: Sandeep Shrivastava
> Fix For: 1.1.0
>
> Attachments: OPENJPA-576-v2.patch, OPENJPA-576-v2.patch, OPENJPA-576.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Consider the following persistent class model. The accessor methods are removed for the sake of brevity.
> public class EmbeddedOwnerPC {
> private int id1;
> private int id2;
> private String stringField;
> private EmbeddedPC embedded;
> private ComplexEmbeddedPC complexEmbedded;
> }
> public class EmbeddedPC {
> private int intField;
> private String stringField;
> }
> public class ComplexEmbeddedPC extends RecursivelyEmbeddedPC {
> private String stringField;
> private EmbeddedOwnerPC ownerField;
> private Set stringSet = new HashSet();
> }
> public class RecursivelyEmbeddedPC {
> private EmbeddedPC embedded;
> }
> When trying to retrieve the EmbeddedOwner entity with a given fetch plan that includes the complexEmbedded and the embedded fields in the RecursivelyEmbeddedPC class it generate the following 2 SQL statements to load the entity.
> SELECT t0.TYP, t0.VERSN, t0.EMBEDDED_NULL, t0.ID1, t0.ID2, t0.INTFIELD1,
> t0.STRINGFIELD3, t0.STRINGFIELD FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ? FOR UPDATE
> SELECT t0.ID1, t0.ID2 FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ?
> FOR UPDATE
> The second call is reduntant and not needed. The fix is to the EmbedFieldStrategy class load method to ensure that all fields that are required to be loaded as per the fetch plan and included from the result set and ONLY when this is not true then generate the extra call otherwise return a hollow embedded entity. In the above test case the extra call was generated to get the stringSet field which was not specified in the fetch plan but the call is made out nevertheless which just selects the primary keys with the same where clause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-576) Recursively embedded entities
generate an extra and reduntant SQL call to the database.
Posted by "Sandeep Shrivastava (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Shrivastava updated OPENJPA-576:
----------------------------------------
Attachment: OPENJPA-576-v2.patch
Revised patch based on comments from Abe.
> Recursively embedded entities generate an extra and reduntant SQL call to the database.
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-576
> URL: https://issues.apache.org/jira/browse/OPENJPA-576
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Environment: OpenJPA 1.1.0-SNAPSHOT
> version id: openjpa-1.1.0-SNAPSHOT-r422266:647033
> Apache svn revision: 422266:647033
> os.name: Windows XP
> os.version: 5.1
> os.arch: x86
> java.version: 1.6.0_05
> java.vendor: BEA Systems, Inc.
> Reporter: Sandeep Shrivastava
> Fix For: 1.1.0
>
> Attachments: OPENJPA-576-v2.patch, OPENJPA-576.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Consider the following persistent class model. The accessor methods are removed for the sake of brevity.
> public class EmbeddedOwnerPC {
> private int id1;
> private int id2;
> private String stringField;
> private EmbeddedPC embedded;
> private ComplexEmbeddedPC complexEmbedded;
> }
> public class EmbeddedPC {
> private int intField;
> private String stringField;
> }
> public class ComplexEmbeddedPC extends RecursivelyEmbeddedPC {
> private String stringField;
> private EmbeddedOwnerPC ownerField;
> private Set stringSet = new HashSet();
> }
> public class RecursivelyEmbeddedPC {
> private EmbeddedPC embedded;
> }
> When trying to retrieve the EmbeddedOwner entity with a given fetch plan that includes the complexEmbedded and the embedded fields in the RecursivelyEmbeddedPC class it generate the following 2 SQL statements to load the entity.
> SELECT t0.TYP, t0.VERSN, t0.EMBEDDED_NULL, t0.ID1, t0.ID2, t0.INTFIELD1,
> t0.STRINGFIELD3, t0.STRINGFIELD FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ? FOR UPDATE
> SELECT t0.ID1, t0.ID2 FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ?
> FOR UPDATE
> The second call is reduntant and not needed. The fix is to the EmbedFieldStrategy class load method to ensure that all fields that are required to be loaded as per the fetch plan and included from the result set and ONLY when this is not true then generate the extra call otherwise return a hollow embedded entity. In the above test case the extra call was generated to get the stringSet field which was not specified in the fetch plan but the call is made out nevertheless which just selects the primary keys with the same where clause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-576) Recursively embedded entities
generate an extra and reduntant SQL call to the database.
Posted by "Sandeep Shrivastava (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Shrivastava updated OPENJPA-576:
----------------------------------------
Attachment: OPENJPA-576-v2.patch
Further refinement of the patch based on feedback from Abe White.
> Recursively embedded entities generate an extra and reduntant SQL call to the database.
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-576
> URL: https://issues.apache.org/jira/browse/OPENJPA-576
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Environment: OpenJPA 1.1.0-SNAPSHOT
> version id: openjpa-1.1.0-SNAPSHOT-r422266:647033
> Apache svn revision: 422266:647033
> os.name: Windows XP
> os.version: 5.1
> os.arch: x86
> java.version: 1.6.0_05
> java.vendor: BEA Systems, Inc.
> Reporter: Sandeep Shrivastava
> Fix For: 1.1.0
>
> Attachments: OPENJPA-576-v2.patch, OPENJPA-576-v2.patch, OPENJPA-576.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Consider the following persistent class model. The accessor methods are removed for the sake of brevity.
> public class EmbeddedOwnerPC {
> private int id1;
> private int id2;
> private String stringField;
> private EmbeddedPC embedded;
> private ComplexEmbeddedPC complexEmbedded;
> }
> public class EmbeddedPC {
> private int intField;
> private String stringField;
> }
> public class ComplexEmbeddedPC extends RecursivelyEmbeddedPC {
> private String stringField;
> private EmbeddedOwnerPC ownerField;
> private Set stringSet = new HashSet();
> }
> public class RecursivelyEmbeddedPC {
> private EmbeddedPC embedded;
> }
> When trying to retrieve the EmbeddedOwner entity with a given fetch plan that includes the complexEmbedded and the embedded fields in the RecursivelyEmbeddedPC class it generate the following 2 SQL statements to load the entity.
> SELECT t0.TYP, t0.VERSN, t0.EMBEDDED_NULL, t0.ID1, t0.ID2, t0.INTFIELD1,
> t0.STRINGFIELD3, t0.STRINGFIELD FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ? FOR UPDATE
> SELECT t0.ID1, t0.ID2 FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ?
> FOR UPDATE
> The second call is reduntant and not needed. The fix is to the EmbedFieldStrategy class load method to ensure that all fields that are required to be loaded as per the fetch plan and included from the result set and ONLY when this is not true then generate the extra call otherwise return a hollow embedded entity. In the above test case the extra call was generated to get the stringSet field which was not specified in the fetch plan but the call is made out nevertheless which just selects the primary keys with the same where clause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-576) Recursively embedded entities
generate an extra and reduntant SQL call to the database.
Posted by "Sandeep Shrivastava (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Shrivastava updated OPENJPA-576:
----------------------------------------
Attachment: OPENJPA-576.patch
Suggested fix for the issue.
> Recursively embedded entities generate an extra and reduntant SQL call to the database.
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-576
> URL: https://issues.apache.org/jira/browse/OPENJPA-576
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Environment: OpenJPA 1.1.0-SNAPSHOT
> version id: openjpa-1.1.0-SNAPSHOT-r422266:647033
> Apache svn revision: 422266:647033
> os.name: Windows XP
> os.version: 5.1
> os.arch: x86
> java.version: 1.6.0_05
> java.vendor: BEA Systems, Inc.
> Reporter: Sandeep Shrivastava
> Fix For: 1.1.0
>
> Attachments: OPENJPA-576.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Consider the following persistent class model. The accessor methods are removed for the sake of brevity.
> public class EmbeddedOwnerPC {
> private int id1;
> private int id2;
> private String stringField;
> private EmbeddedPC embedded;
> private ComplexEmbeddedPC complexEmbedded;
> }
> public class EmbeddedPC {
> private int intField;
> private String stringField;
> }
> public class ComplexEmbeddedPC extends RecursivelyEmbeddedPC {
> private String stringField;
> private EmbeddedOwnerPC ownerField;
> private Set stringSet = new HashSet();
> }
> public class RecursivelyEmbeddedPC {
> private EmbeddedPC embedded;
> }
> When trying to retrieve the EmbeddedOwner entity with a given fetch plan that includes the complexEmbedded and the embedded fields in the RecursivelyEmbeddedPC class it generate the following 2 SQL statements to load the entity.
> SELECT t0.TYP, t0.VERSN, t0.EMBEDDED_NULL, t0.ID1, t0.ID2, t0.INTFIELD1,
> t0.STRINGFIELD3, t0.STRINGFIELD FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ? FOR UPDATE
> SELECT t0.ID1, t0.ID2 FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ?
> FOR UPDATE
> The second call is reduntant and not needed. The fix is to the EmbedFieldStrategy class load method to ensure that all fields that are required to be loaded as per the fetch plan and included from the result set and ONLY when this is not true then generate the extra call otherwise return a hollow embedded entity. In the above test case the extra call was generated to get the stringSet field which was not specified in the fetch plan but the call is made out nevertheless which just selects the primary keys with the same where clause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-576) Recursively embedded entities
generate an extra and reduntant SQL call to the database.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590988#action_12590988 ]
Patrick Linskey commented on OPENJPA-576:
-----------------------------------------
- // after loading everything from result, load the rest of the
- // configured fields
- if (loaded)
- em.load(fetch);
+ // After loading everything from result, load the rest of the
+ // configured fields if anything is missing.
+ if (!loaded) {
+ em.load(fetch);
+ }
This seems like a relatively significant semantic change. Can you describe why you inverted the initialization value of |loaded| and why you changed this logic at the end?
Also, what tests have you run this fix against?
> Recursively embedded entities generate an extra and reduntant SQL call to the database.
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-576
> URL: https://issues.apache.org/jira/browse/OPENJPA-576
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Environment: OpenJPA 1.1.0-SNAPSHOT
> version id: openjpa-1.1.0-SNAPSHOT-r422266:647033
> Apache svn revision: 422266:647033
> os.name: Windows XP
> os.version: 5.1
> os.arch: x86
> java.version: 1.6.0_05
> java.vendor: BEA Systems, Inc.
> Reporter: Sandeep Shrivastava
> Fix For: 1.1.0
>
> Attachments: OPENJPA-576.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Consider the following persistent class model. The accessor methods are removed for the sake of brevity.
> public class EmbeddedOwnerPC {
> private int id1;
> private int id2;
> private String stringField;
> private EmbeddedPC embedded;
> private ComplexEmbeddedPC complexEmbedded;
> }
> public class EmbeddedPC {
> private int intField;
> private String stringField;
> }
> public class ComplexEmbeddedPC extends RecursivelyEmbeddedPC {
> private String stringField;
> private EmbeddedOwnerPC ownerField;
> private Set stringSet = new HashSet();
> }
> public class RecursivelyEmbeddedPC {
> private EmbeddedPC embedded;
> }
> When trying to retrieve the EmbeddedOwner entity with a given fetch plan that includes the complexEmbedded and the embedded fields in the RecursivelyEmbeddedPC class it generate the following 2 SQL statements to load the entity.
> SELECT t0.TYP, t0.VERSN, t0.EMBEDDED_NULL, t0.ID1, t0.ID2, t0.INTFIELD1,
> t0.STRINGFIELD3, t0.STRINGFIELD FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ? FOR UPDATE
> SELECT t0.ID1, t0.ID2 FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ?
> FOR UPDATE
> The second call is reduntant and not needed. The fix is to the EmbedFieldStrategy class load method to ensure that all fields that are required to be loaded as per the fetch plan and included from the result set and ONLY when this is not true then generate the extra call otherwise return a hollow embedded entity. In the above test case the extra call was generated to get the stringSet field which was not specified in the fetch plan but the call is made out nevertheless which just selects the primary keys with the same where clause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-576) Recursively embedded entities
generate an extra and reduntant SQL call to the database.
Posted by "Patrick Linskey (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591213#action_12591213 ]
Patrick Linskey commented on OPENJPA-576:
-----------------------------------------
>From a conversation with Sandeep:
> We initialize the boolean loaded = true; so we go with the assumption
> that we don't need to reload anything and everything we need is already
> in the result set. The variable gets set to false only if a required
> field is not loaded as per the fetch configuration and then we retry
>
> if (!loaded) {
> em.load(fetch);
> }
>
> So the embedded entity remains hollow if some of the fields are not
> present in the result set and they are not present in the fetch
> configuration.
> Recursively embedded entities generate an extra and reduntant SQL call to the database.
> ---------------------------------------------------------------------------------------
>
> Key: OPENJPA-576
> URL: https://issues.apache.org/jira/browse/OPENJPA-576
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Environment: OpenJPA 1.1.0-SNAPSHOT
> version id: openjpa-1.1.0-SNAPSHOT-r422266:647033
> Apache svn revision: 422266:647033
> os.name: Windows XP
> os.version: 5.1
> os.arch: x86
> java.version: 1.6.0_05
> java.vendor: BEA Systems, Inc.
> Reporter: Sandeep Shrivastava
> Fix For: 1.1.0
>
> Attachments: OPENJPA-576.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Consider the following persistent class model. The accessor methods are removed for the sake of brevity.
> public class EmbeddedOwnerPC {
> private int id1;
> private int id2;
> private String stringField;
> private EmbeddedPC embedded;
> private ComplexEmbeddedPC complexEmbedded;
> }
> public class EmbeddedPC {
> private int intField;
> private String stringField;
> }
> public class ComplexEmbeddedPC extends RecursivelyEmbeddedPC {
> private String stringField;
> private EmbeddedOwnerPC ownerField;
> private Set stringSet = new HashSet();
> }
> public class RecursivelyEmbeddedPC {
> private EmbeddedPC embedded;
> }
> When trying to retrieve the EmbeddedOwner entity with a given fetch plan that includes the complexEmbedded and the embedded fields in the RecursivelyEmbeddedPC class it generate the following 2 SQL statements to load the entity.
> SELECT t0.TYP, t0.VERSN, t0.EMBEDDED_NULL, t0.ID1, t0.ID2, t0.INTFIELD1,
> t0.STRINGFIELD3, t0.STRINGFIELD FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ? FOR UPDATE
> SELECT t0.ID1, t0.ID2 FROM EMBEDDEDOWNERPC t0 WHERE t0.ID1 = ? AND t0.ID2 = ?
> FOR UPDATE
> The second call is reduntant and not needed. The fix is to the EmbedFieldStrategy class load method to ensure that all fields that are required to be loaded as per the fetch plan and included from the result set and ONLY when this is not true then generate the extra call otherwise return a hollow embedded entity. In the above test case the extra call was generated to get the stringSet field which was not specified in the fetch plan but the call is made out nevertheless which just selects the primary keys with the same where clause.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.