【问题标题】:EJB3 - handling non-standard link tablesEJB3 - 处理非标准链接表
【发布时间】:2010-10-22 14:18:01
【问题描述】:

我有一种情况,我正在使用 EJB3 和旧数据库。我有一种情况,两个表 A 和 B 之间存在多对多关系,通过第三个(链接)表 L 定义。

复杂之处在于链接表中除了表A和B的PK之外还有其他字段。这些列是标准时间戳和用户列,用于记录谁生成了链接。这两个额外的列阻止我使用连接表注释定义多对多关系,因为它们不可为空,因此必须填充。

有人知道绕过这个限制的方法吗?我可以定义从链接表到关系中其他每个表的一对多关系,但这不是很优雅。

谢谢,

【问题讨论】:

    标签: java jpa ejb-3.0 java-ee-5


    【解决方案1】:

    是的,但你需要让它优雅。以下超类可用于将任意多对多关系定义为实体:

    @MappedSuperclass
    public abstract class ModelBaseRelationship {
    
        @Embeddable
        public static class Id implements Serializable {
    
            public Long entityId1;
            public Long entityId2;
    
            @Column(name = "ENTITY1_ID")
            public Long getEntityId1() {
                return entityId1;
            }
    
            @Column(name = "ENTITY2_ID")
            public Long getEntityId2() {
                return entityId2;
            }
    
            public Id() {
            }
    
            public Id(Long entityId1, Long entityId2) {
                this.entityId1 = entityId1;
                this.entityId2 = entityId2;
            }
    
            @Override
            public boolean equals(Object other) {
                if (other == null)
                    return false;
                if (this == other)
                    return true;
                if (!(other instanceof Id))
                    return false;
                final Id that = (Id) other;
                return new EqualsBuilder().append(this.entityId1, that.getEntityId1()).append(this.entityId1, that.getEntityId2()).isEquals();
            }
    
            @Override
            public int hashCode() {
                return new HashCodeBuilder(11, 111).append(this.entityId1).append(this.entityId2).toHashCode();
            }
    
            protected void setEntityId1(Long theEntityId1) {
                entityId1 = theEntityId1;
            }
    
            protected void setEntityId2(Long theEntityId2) {
                entityId2 = theEntityId2;
            }
        }
    
        protected Id id = new Id();
    
        public ModelBaseRelationship() {
            super();
        }
    
        public ModelBaseRelationship(ModelBaseEntity entity1, ModelBaseEntity entity2) {
            this();
            this.id.entityId1 = entity1.getId();
            this.id.entityId2 = entity2.getId();
            setVersion(0);
        }
    
        @EmbeddedId
        public Id getId() {
            return id;
        }
    
        protected void setId(Id theId) {
            id = theId;
        }
    
    }
    

    基于这个超类(片段)的实体示例:

    @Entity(name = "myRealEntity")
    @Table(name = "REAL_TABLE_NAME", uniqueConstraints = { @UniqueConstraint(columnNames = {
     "FIRST_FK_ID", "SECOND_FK_ID" }) })
    @AttributeOverrides( {
    @AttributeOverride(name = "entityId1", column = @Column(name = "FIRST_FK_ID")),
    @AttributeOverride(name = "entityId2", column = @Column(name = "SECOND_FK_ID"))    
    })
    public class ModelBaseRelationshipReferenceImpl extends ModelBaseRelationship {
    
      private Entity1OfManyToManyRelationship entity1;
      private Entity2OfManyToManyRelationship entity2;
      ...
      @ManyToOne
      @JoinColumn(name = "FIRST_FK_ID", insertable = false, updatable = false)
      public Entity1OfManyToManyRelationship getEntity1OfManyToManyRelationship() {
        return entity1;
      }
    
      @ManyToOne
      @JoinColumn(name = "SECOND_FK_ID", insertable = false, updatable = false)
      public Entity2OfManyToManyRelationship getEntity2OfManyToManyRelationship () {
        return entity2;
      }
    ...
    }
    

    【讨论】:

    • 您好,Grigory,感谢您的回复,但我不确定我是否正确地关注了您。这实际上给了你什么?目前它在 A 和 B 上使用 @ManyToOne 注释,在 L 上使用 OneToMany - 我宁愿摆脱对 L(作为实体)的需要。我不太确定你的超类在这里实现了什么。
    • 它做了以下事情:它将链接表定义为一个完整的实体,保持链接表的唯一键、主键结构。我将编辑最后一个示例以添加关系以使其清晰。
    • 超类是真正的抽象类,它可以让您重用大量代码,以防您将多个链接表作为一个实体... 抱歉之前没有澄清这一点。如果您不需要重复使用,您可以轻松地将其折叠成单个实体类。
    猜你喜欢
    • 2010-10-14
    • 2013-11-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-06-05
    相关资源
    最近更新 更多