简体   繁体   English

通过非PK列的Hibernate ManyToOne JOIN抛出“类型int的错误值”

[英]Hibernate ManyToOne JOIN by non-PK column throws “Bad value for type int”

First of all let me make my scenario clear I am using hibernate 4.3 ,Postgresql 9.3 with spring MVC ,and I have reverse engineered classes using JBOSS tool. 首先让我让我的场景清楚我正在使用hibernate 4.3,Postgresql 9.3和spring MVC,我使用JBOSS工具进行逆向工程。

Every time I select the data using HQL or session.get() I am getting (SQL queries are working fine) Caused by : org.postgresql.util.PSQLException: Bad value for type int : demoemailaddr@gmail.com 我每次使用HQL或session.get()选择数据时(SQL查询工作正常)引起:org.postgresql.util.PSQLException:int类型的错误值:demoemailaddr@gmail.com

Entity classes, 实体类,
Applicant.java Applicant.java

@Entity
@Table(name = "applicant", schema = "public", uniqueConstraints = { @UniqueConstraint(columnNames = "user_id"), @UniqueConstraint(columnNames = "email"), @UniqueConstraint(columnNames = "registration_id") })
public class Applicant implements java.io.Serializable
{
    @Id
    @Column(name = "application_id", unique = true, nullable = false, length = 7)
    private String applicationId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "email", unique = true, nullable = false)
    private Users usersByEmail;

     // setters and getters
}

and Users class which has @ManytOne relationship with above class. 和与上面的类有@ManytOne关系的Users类。

@Entity
@Table(name = "users", schema = "public", uniqueConstraints = { @UniqueConstraint(columnNames = "email"), @UniqueConstraint(columnNames = "application_id") })
public class Users implements java.io.Serializable
{
    @Id
    @Column(name = "user_id", unique = true, nullable = false)
    private int userId;

    @Column(name = "email", unique = true, nullable = false, length = 100)
    private String email;

}

Now check the schema structure 现在检查架构结构

CREATE TABLE users
(
  email character varying(100) NOT NULL,
  user_id integer NOT NULL,
  CONSTRAINT users_pk PRIMARY KEY (user_id),
  CONSTRAINT unique_email UNIQUE (email)
)

 CREATE TABLE applicant
(
  application_id character(7) NOT NULL,
  email character varying(100) NOT NULL,
  CONSTRAINT users_email_fk FOREIGN KEY (email)
  REFERENCES users (email) MATCH SIMPLE
  ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT unique_applicant_email UNIQUE (email)
 )

[Edited] I am using join column on email of user table which has Unique constraint but not it's not PK(PK is user_id) [已编辑]我在用户表的电子邮件中使用连接列,该用户表具有唯一约束但不是它不是PK(PK是user_id)
PS:I can't change db schema structure, I don't have authority PS:我无法更改数据库架构结构,我没有权限

You need to add the referencedColumnName attribute to the @ManyToOne association: 您需要将referencedColumnName属性添加到@ManyToOne关联:

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "email", referencedColumnName = "email", unique = true, nullable = false)
private Users usersByEmail;

You defined joinColumn as email, the EMAIL column from your applicant table will be used when creating the joins (which is varchar holding email values). 您将joinColumn定义为电子邮件,创建连接时将使用您的申请人表中的EMAIL列(即varchar保留电子邮件值)。 But the joins are done by @ID annotated field, which for user is userId and it is numerical, so you get the exception. 但是连接是由@ID带注释的字段完成的,对于用户而言是userId并且它是数字的,所以你得到了异常。

Join is always by @ID, field, the joincolumn tells only where it should be stored in the join or local table. Join总是通过@ID,field,joincolumn只告诉它应该存储在join或local表中的哪个位置。

you need to either define a primary key in the database (instead of multiple unique fields) or use reveng.xml to tell hibernate tools what is the true primary key. 您需要在数据库中定义主键(而不是多个唯一字段)或使用reveng.xml告诉hibernate工具什么是真正的主键。

You need something like: 你需要这样的东西:

<table name="applicant"> 
 <primary-key>
  <key-column name="application_id"/>
 </primary-key>
</table>

you can see details in the docs at: http://docs.jboss.org/tools/latest/en/hibernatetools/html/reverseengineering.html 您可以在以下文档中查看详细信息: http//docs.jboss.org/tools/latest/en/hibernatetools/html/reverseengineering.html

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM