JPA (EclipseLink) SecondaryTable erroneous join with java 1.7












0















I have created an entity joining Customer table with Customer detail table using SecondaryTable annotation



@Entity
@Table(name="CUSTOMER")
@SecondaryTable(name="CUST_DETAIL",
pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
public class Customer {
@Id
@Column(name = "CUST_ID")
private Long id;

@Column(name = "CUST_DETAIL_ID")
private Long custDetailPk;

@Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
private Long custDetailId;

...
}


It is working with java 1.6, the generated query is like



SELECT t0.CUST_ID, t0.CUST_DETAIL_ID, t1.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t0.CUST_DETAIL_ID


but when I migrate to java 1.7, the generated query seams erroneous



SELECT t0.CUST_ID, t1.CUST_DETAIL_ID, t0.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t1.CUST_DETAIL_ID


and returning multiple rows.



Is there any problem with jpa secondarytable and java 1.7?










share|improve this question

























  • Do you still use the same version of Hibernate?

    – Simon Martinelli
    Nov 21 '18 at 9:32











  • You mean, do you still use the same version of EclipseLink ...

    – Billy Frost
    Nov 21 '18 at 9:38











  • Yes, I am using the same version of EclipseLink. I have tried several new versions with the same result.

    – Vitalino
    Nov 21 '18 at 10:53













  • Why do you have the same field (CUST_DETAIL.CUST_DETAIL_ID) mapped twice? The custDetailId should not be there or annotated as part of the primary key as it is not - the field is set from the custDetailfk value through the SecondaryTable mapping. I don't know why there is a difference in the JVM processing, but I suspect having multiple mappings is getting processed in a different order, so that the extra mapping is being used for the equals check in your queries instead of the one on the main table.

    – Chris
    Nov 21 '18 at 14:47











  • It also doesn't make sense why both CUST_DETAIL_ID and CUST_ID are IDs for the CUSTOMER when CUST_DETAIL_ID is unique enough to use for the mandatory CUST_DETAIL rows. Wouldn't just CUST_DETAIL_ID be usable for an ID, or should CUST_ID == CUST_DETAIL_ID? If they do not, it seems like the CUST_DETAIL table should treated as its own entity class with a 1:1 relationship

    – Chris
    Nov 21 '18 at 14:50
















0















I have created an entity joining Customer table with Customer detail table using SecondaryTable annotation



@Entity
@Table(name="CUSTOMER")
@SecondaryTable(name="CUST_DETAIL",
pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
public class Customer {
@Id
@Column(name = "CUST_ID")
private Long id;

@Column(name = "CUST_DETAIL_ID")
private Long custDetailPk;

@Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
private Long custDetailId;

...
}


It is working with java 1.6, the generated query is like



SELECT t0.CUST_ID, t0.CUST_DETAIL_ID, t1.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t0.CUST_DETAIL_ID


but when I migrate to java 1.7, the generated query seams erroneous



SELECT t0.CUST_ID, t1.CUST_DETAIL_ID, t0.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t1.CUST_DETAIL_ID


and returning multiple rows.



Is there any problem with jpa secondarytable and java 1.7?










share|improve this question

























  • Do you still use the same version of Hibernate?

    – Simon Martinelli
    Nov 21 '18 at 9:32











  • You mean, do you still use the same version of EclipseLink ...

    – Billy Frost
    Nov 21 '18 at 9:38











  • Yes, I am using the same version of EclipseLink. I have tried several new versions with the same result.

    – Vitalino
    Nov 21 '18 at 10:53













  • Why do you have the same field (CUST_DETAIL.CUST_DETAIL_ID) mapped twice? The custDetailId should not be there or annotated as part of the primary key as it is not - the field is set from the custDetailfk value through the SecondaryTable mapping. I don't know why there is a difference in the JVM processing, but I suspect having multiple mappings is getting processed in a different order, so that the extra mapping is being used for the equals check in your queries instead of the one on the main table.

    – Chris
    Nov 21 '18 at 14:47











  • It also doesn't make sense why both CUST_DETAIL_ID and CUST_ID are IDs for the CUSTOMER when CUST_DETAIL_ID is unique enough to use for the mandatory CUST_DETAIL rows. Wouldn't just CUST_DETAIL_ID be usable for an ID, or should CUST_ID == CUST_DETAIL_ID? If they do not, it seems like the CUST_DETAIL table should treated as its own entity class with a 1:1 relationship

    – Chris
    Nov 21 '18 at 14:50














0












0








0








I have created an entity joining Customer table with Customer detail table using SecondaryTable annotation



@Entity
@Table(name="CUSTOMER")
@SecondaryTable(name="CUST_DETAIL",
pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
public class Customer {
@Id
@Column(name = "CUST_ID")
private Long id;

@Column(name = "CUST_DETAIL_ID")
private Long custDetailPk;

@Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
private Long custDetailId;

...
}


It is working with java 1.6, the generated query is like



SELECT t0.CUST_ID, t0.CUST_DETAIL_ID, t1.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t0.CUST_DETAIL_ID


but when I migrate to java 1.7, the generated query seams erroneous



SELECT t0.CUST_ID, t1.CUST_DETAIL_ID, t0.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t1.CUST_DETAIL_ID


and returning multiple rows.



Is there any problem with jpa secondarytable and java 1.7?










share|improve this question
















I have created an entity joining Customer table with Customer detail table using SecondaryTable annotation



@Entity
@Table(name="CUSTOMER")
@SecondaryTable(name="CUST_DETAIL",
pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
public class Customer {
@Id
@Column(name = "CUST_ID")
private Long id;

@Column(name = "CUST_DETAIL_ID")
private Long custDetailPk;

@Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
private Long custDetailId;

...
}


It is working with java 1.6, the generated query is like



SELECT t0.CUST_ID, t0.CUST_DETAIL_ID, t1.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t0.CUST_DETAIL_ID


but when I migrate to java 1.7, the generated query seams erroneous



SELECT t0.CUST_ID, t1.CUST_DETAIL_ID, t0.CUST_DETAIL_ID, ... FROM CUSTOMER t0, CUST_DETAIL t1 WHERE t1.CUST_DETAIL_ID = t1.CUST_DETAIL_ID


and returning multiple rows.



Is there any problem with jpa secondarytable and java 1.7?







java jpa eclipselink






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 30 '18 at 11:27







Vitalino

















asked Nov 21 '18 at 9:09









VitalinoVitalino

13




13













  • Do you still use the same version of Hibernate?

    – Simon Martinelli
    Nov 21 '18 at 9:32











  • You mean, do you still use the same version of EclipseLink ...

    – Billy Frost
    Nov 21 '18 at 9:38











  • Yes, I am using the same version of EclipseLink. I have tried several new versions with the same result.

    – Vitalino
    Nov 21 '18 at 10:53













  • Why do you have the same field (CUST_DETAIL.CUST_DETAIL_ID) mapped twice? The custDetailId should not be there or annotated as part of the primary key as it is not - the field is set from the custDetailfk value through the SecondaryTable mapping. I don't know why there is a difference in the JVM processing, but I suspect having multiple mappings is getting processed in a different order, so that the extra mapping is being used for the equals check in your queries instead of the one on the main table.

    – Chris
    Nov 21 '18 at 14:47











  • It also doesn't make sense why both CUST_DETAIL_ID and CUST_ID are IDs for the CUSTOMER when CUST_DETAIL_ID is unique enough to use for the mandatory CUST_DETAIL rows. Wouldn't just CUST_DETAIL_ID be usable for an ID, or should CUST_ID == CUST_DETAIL_ID? If they do not, it seems like the CUST_DETAIL table should treated as its own entity class with a 1:1 relationship

    – Chris
    Nov 21 '18 at 14:50



















  • Do you still use the same version of Hibernate?

    – Simon Martinelli
    Nov 21 '18 at 9:32











  • You mean, do you still use the same version of EclipseLink ...

    – Billy Frost
    Nov 21 '18 at 9:38











  • Yes, I am using the same version of EclipseLink. I have tried several new versions with the same result.

    – Vitalino
    Nov 21 '18 at 10:53













  • Why do you have the same field (CUST_DETAIL.CUST_DETAIL_ID) mapped twice? The custDetailId should not be there or annotated as part of the primary key as it is not - the field is set from the custDetailfk value through the SecondaryTable mapping. I don't know why there is a difference in the JVM processing, but I suspect having multiple mappings is getting processed in a different order, so that the extra mapping is being used for the equals check in your queries instead of the one on the main table.

    – Chris
    Nov 21 '18 at 14:47











  • It also doesn't make sense why both CUST_DETAIL_ID and CUST_ID are IDs for the CUSTOMER when CUST_DETAIL_ID is unique enough to use for the mandatory CUST_DETAIL rows. Wouldn't just CUST_DETAIL_ID be usable for an ID, or should CUST_ID == CUST_DETAIL_ID? If they do not, it seems like the CUST_DETAIL table should treated as its own entity class with a 1:1 relationship

    – Chris
    Nov 21 '18 at 14:50

















Do you still use the same version of Hibernate?

– Simon Martinelli
Nov 21 '18 at 9:32





Do you still use the same version of Hibernate?

– Simon Martinelli
Nov 21 '18 at 9:32













You mean, do you still use the same version of EclipseLink ...

– Billy Frost
Nov 21 '18 at 9:38





You mean, do you still use the same version of EclipseLink ...

– Billy Frost
Nov 21 '18 at 9:38













Yes, I am using the same version of EclipseLink. I have tried several new versions with the same result.

– Vitalino
Nov 21 '18 at 10:53







Yes, I am using the same version of EclipseLink. I have tried several new versions with the same result.

– Vitalino
Nov 21 '18 at 10:53















Why do you have the same field (CUST_DETAIL.CUST_DETAIL_ID) mapped twice? The custDetailId should not be there or annotated as part of the primary key as it is not - the field is set from the custDetailfk value through the SecondaryTable mapping. I don't know why there is a difference in the JVM processing, but I suspect having multiple mappings is getting processed in a different order, so that the extra mapping is being used for the equals check in your queries instead of the one on the main table.

– Chris
Nov 21 '18 at 14:47





Why do you have the same field (CUST_DETAIL.CUST_DETAIL_ID) mapped twice? The custDetailId should not be there or annotated as part of the primary key as it is not - the field is set from the custDetailfk value through the SecondaryTable mapping. I don't know why there is a difference in the JVM processing, but I suspect having multiple mappings is getting processed in a different order, so that the extra mapping is being used for the equals check in your queries instead of the one on the main table.

– Chris
Nov 21 '18 at 14:47













It also doesn't make sense why both CUST_DETAIL_ID and CUST_ID are IDs for the CUSTOMER when CUST_DETAIL_ID is unique enough to use for the mandatory CUST_DETAIL rows. Wouldn't just CUST_DETAIL_ID be usable for an ID, or should CUST_ID == CUST_DETAIL_ID? If they do not, it seems like the CUST_DETAIL table should treated as its own entity class with a 1:1 relationship

– Chris
Nov 21 '18 at 14:50





It also doesn't make sense why both CUST_DETAIL_ID and CUST_ID are IDs for the CUSTOMER when CUST_DETAIL_ID is unique enough to use for the mandatory CUST_DETAIL rows. Wouldn't just CUST_DETAIL_ID be usable for an ID, or should CUST_ID == CUST_DETAIL_ID? If they do not, it seems like the CUST_DETAIL table should treated as its own entity class with a 1:1 relationship

– Chris
Nov 21 '18 at 14:50












1 Answer
1






active

oldest

votes


















0














The solution comes from avoiding the confusión caused by the names of the fields CUST_DETAIL_ID, JPA needs to know what table belongs, and the name of the properties custDetailId and custDetailPk that it must be ordered alphabetically.



@Entity
@Table(name="CUSTOMER")
@SecondaryTable(name="CUST_DETAIL",
pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
public class Customer {
@Id
@Column(name = "CUST_ID")
private Long id;

@Column(name = "CUST_DETAIL_ID", table = "CUSTOMER")
private Long custDetailId;

@Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
private Long custDetailPk;

...
}





share|improve this answer

























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408569%2fjpa-eclipselink-secondarytable-erroneous-join-with-java-1-7%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    The solution comes from avoiding the confusión caused by the names of the fields CUST_DETAIL_ID, JPA needs to know what table belongs, and the name of the properties custDetailId and custDetailPk that it must be ordered alphabetically.



    @Entity
    @Table(name="CUSTOMER")
    @SecondaryTable(name="CUST_DETAIL",
    pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
    public class Customer {
    @Id
    @Column(name = "CUST_ID")
    private Long id;

    @Column(name = "CUST_DETAIL_ID", table = "CUSTOMER")
    private Long custDetailId;

    @Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
    private Long custDetailPk;

    ...
    }





    share|improve this answer






























      0














      The solution comes from avoiding the confusión caused by the names of the fields CUST_DETAIL_ID, JPA needs to know what table belongs, and the name of the properties custDetailId and custDetailPk that it must be ordered alphabetically.



      @Entity
      @Table(name="CUSTOMER")
      @SecondaryTable(name="CUST_DETAIL",
      pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
      public class Customer {
      @Id
      @Column(name = "CUST_ID")
      private Long id;

      @Column(name = "CUST_DETAIL_ID", table = "CUSTOMER")
      private Long custDetailId;

      @Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
      private Long custDetailPk;

      ...
      }





      share|improve this answer




























        0












        0








        0







        The solution comes from avoiding the confusión caused by the names of the fields CUST_DETAIL_ID, JPA needs to know what table belongs, and the name of the properties custDetailId and custDetailPk that it must be ordered alphabetically.



        @Entity
        @Table(name="CUSTOMER")
        @SecondaryTable(name="CUST_DETAIL",
        pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
        public class Customer {
        @Id
        @Column(name = "CUST_ID")
        private Long id;

        @Column(name = "CUST_DETAIL_ID", table = "CUSTOMER")
        private Long custDetailId;

        @Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
        private Long custDetailPk;

        ...
        }





        share|improve this answer















        The solution comes from avoiding the confusión caused by the names of the fields CUST_DETAIL_ID, JPA needs to know what table belongs, and the name of the properties custDetailId and custDetailPk that it must be ordered alphabetically.



        @Entity
        @Table(name="CUSTOMER")
        @SecondaryTable(name="CUST_DETAIL",
        pkJoinColumns=@PrimaryKeyJoinColumn(name="CUST_DETAIL_ID", referencedColumnName = "CUST_DETAIL_ID"))
        public class Customer {
        @Id
        @Column(name = "CUST_ID")
        private Long id;

        @Column(name = "CUST_DETAIL_ID", table = "CUSTOMER")
        private Long custDetailId;

        @Column(name = "CUST_DETAIL_ID", table = "CUST_DETAIL")
        private Long custDetailPk;

        ...
        }






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 30 '18 at 11:26

























        answered Nov 26 '18 at 11:49









        VitalinoVitalino

        13




        13
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408569%2fjpa-eclipselink-secondarytable-erroneous-join-with-java-1-7%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            這個網誌中的熱門文章

            Tangent Lines Diagram Along Smooth Curve

            Yusuf al-Mu'taman ibn Hud

            Zucchini