JPA (EclipseLink) SecondaryTable erroneous join with java 1.7
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
add a comment |
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
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
add a comment |
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
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
java jpa eclipselink
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
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;
...
}
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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;
...
}
add a comment |
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;
...
}
add a comment |
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;
...
}
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;
...
}
edited Nov 30 '18 at 11:26
answered Nov 26 '18 at 11:49
VitalinoVitalino
13
13
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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