Зачем мне нужно было тройное аннотирование имени столбца MappedSuperClass - PullRequest
Новая
       8

Зачем мне нужно было тройное аннотирование имени столбца MappedSuperClass

0 голосов
/ 28 мая 2020

У меня был базовый класс сущности (не обращайте внимания на то, что id может быть здесь для этого примера): 

@MappedSuperClass
public class BaseTimeEntity implements Serializable {
    @CreationTimestamp
    @Column(name = "time_created")
    protected Timestamp timeCreated;

    @UpdateTimestamp
    @Column(name = "time_updated")
    protected Timestamp timeUpdated;

    public Timestamp getTimeCreated() { return timeCreated; }

    public void setTimeCreated(Timestamp timeCreated) { this.timeCreated = timeCreated; }

    public Timestamp getTimeUpdated() { return timeUpdated; }

    public void setTimeUpdated(Timestamp timeUpdated) { this.timeUpdated = timeUpdated; }
}

И у меня была существующая сущность, с радостью использующая его: 

@Entity
@Table(name = "owner")
public class Owner extends BaseTimeEntity implements Serializable {
    @Id
    @GeneratedValue(strategy= GenerationType.IDENTITY)
    private Integer id;

    @Column
    private String name;
    public Owner(Integer ownerId) { this.id = ownerId; }

    public void setId(Integer id) { this.id = id; }

    public Integer getId() { return this.id; }

    public void setName(String name) { this.name = name; }

    public String getName() { return this.name; }
}

Когда я добавил еще один объект, я обнаружил, что новый объект, столбец, пытался использовать имя столбца timeCreated вместо time_created

@Entity
@Table(name = "comment")
public class Comment extends BaseTimeEntity implements Serializable {
    @Id
    @GeneratedValue(strategy= GenerationType.IDENTITY)
    private Integer id;

    private String message;

    public Integer getId() { return this.id; }

    public void setId(Integer id) { this.id = id; }

    @Column(name = "message")
    public String getMessage() { return message; }

    public void setMessage(String message) { message = message; }
}

Не знаю, почему тот же базовый класс использовал другой столбец

Итак, я обновил базовый класс до: 

@MappedSuperClass
public class BaseTimeEntity implements Serializable {
    protected Timestamp timeCreated;

    protected Timestamp timeUpdated;

    @CreationTimestamp
    @Column(name = "time_created")
    public Timestamp getTimeCreated() { return timeCreated; }

    public void setTimeCreated(Timestamp timeCreated) { this.timeCreated = timeCreated; }

    @UpdateTimestamp
    @Column(name = "time_updated")
    public Timestamp getTimeUpdated() { return timeUpdated; }

    public void setTimeUpdated(Timestamp timeUpdated) { this.timeUpdated = timeUpdated; }
}

И ура, новая сущность, столбец, использовала time_created. Но НЕТ старый объект, владелец, не начал использовать timeCreated вместо time_created.

Поэтому я поместил аннотацию везде в трех экземплярах: 

@MappedSuperClass
public class BaseTimeEntity implements Serializable {
    @CreationTimestamp
    @Column(name = "time_created")
    protected Timestamp timeCreated;

    @UpdateTimestamp
    @Column(name = "time_updated")
    protected Timestamp timeUpdated;

    @CreationTimestamp
    @Column(name = "time_created")
    public Timestamp getTimeCreated() { return timeCreated; }

    @CreationTimestamp
    @Column(name = "time_created")
    public void setTimeCreated(Timestamp timeCreated) { this.timeCreated = timeCreated; }

    @UpdateTimestamp
    @Column(name = "time_updated")
    public Timestamp getTimeUpdated() { return timeUpdated; }

    @UpdateTimestamp
    @Column(name = "time_updated")
    public void setTimeUpdated(Timestamp timeUpdated) { this.timeUpdated = timeUpdated; }
}

Теперь это работает, но кажется довольно бедный по стилю. Почему обе сущности изменили поведение в отношении того, что они используют для наименования столбца?

1 Ответ

0 голосов
/ 28 июля 2020

Похоже, @SternK был прав в том, что стратегии доступа нельзя смешивать. Простое обеспечение того, чтобы все аннотации столбцов были в полях, только сериализация и десериализация в БД работали.

Было бы особенно полезно, если бы какой-либо смешанный регистр приводил к ошибкам компилятора.

...