使用 Hibernate 连接子类,是否可以复制超级表和子表中的列*并*保持它们同步?

发布于 2024-11-07 21:33:34 字数 1234 浏览 4 评论 0原文

所以我有一个有趣的情况。我继承了一大堆乱七八糟的代码,原始开发人员决定放弃使用继承,转而使用枚举和 switch 语句……这是 这种反模式 现在是时候重构了,我决定最好的方法是提取一个由具有共享列的表支持的超类,然后使用加入的子类继承策略。到目前为止一切顺利...

现在棘手的部分是该代码已经部署到生产系统中。因此,我重构的代码必须与那里的架构/数据向后兼容,并且在未来发布一个版本之前我无法开始从子类表中删除冗余列。不管你喜欢与否,我将在一个发布周期的父表和子表之间有重复的列。

对我来说幸运的是,当 hibernate 发现父表和子表之间存在重复列时,它不会崩溃。但坏消息是它不会更新两个表中的重复列。父表中的列已更新,但子表中的列已过时。

为了与当前代码向后兼容,我希望在两个表中更新该列。这样,如果我们必须回滚版本并返回到旧模式,对实体的更新就不会丢失。虽然我知道我可以通过触发器来解决这个问题,但我正在寻找一种仅代码的解决方案,因为触发器有一个在雷达下飞行的讨厌习惯。

有没有人可以告诉我一种方法来说服休眠同时击中两列?

我的类的一个非常人为的示例是:

@Entity
@Table(name = "superclass")
@Inheritance(strategy = InheritanceType.JOINED)
public class SuperClass {

    @Id @Generated
    Long id;
    boolean duplicate;
}

@Entity
@Table(name = "subclass")
public class SubClass extends SuperClass {
    String otherProperty;
}

与表匹配:

CREATE TABLE superclass (
    id INT PRIMARY KEY AUTO_INCREMENT,
    duplicate BOOLEAN
);

CREATE TABLE subclass (
    id INT NOT NULL,
    duplicate BOOLEAN,
    otherProperty VARCHAR(255),
    FOREIGN KEY (id) REFERENCES superclass(id)
);

当插入新的子类实体时,子类表上的重复列将为 NULL。

非常感谢!

So I have an interesting situation. I've inherited a big mess of code where the original developer decided to forego using inheritance in favor of enums and switch statements...it's a perfect example of this anti-pattern Now it's time to refactor, and I've decided the best way to go about it is to pull out a superclass backed by a table with shared columns and then use the joined subclass inheritance strategy. So far so good...

Now the tricky part is that this code has already been deployed to a production system. Accordingly, my refactored code has to be backwards-compatible with the schema/data out there, and I can't start dropping redundant columns off of the subclass tables until one release in the future. Like it or not, I'm going to have duplicated columns between the parent and child tables for one release cycle.

Luckily for me, hibernate doesn't flip out when it sees that there are duplicate columns between parent and child tables. But the bad news is that it doesn't update said duplicated columns in both tables. The column in the parent table gets updated, but the one in the child is left stale.

For backward-compatibility with the current code, I'd like for the column to be updated in both tables. That way, updates to the entities aren't lost if we have to rollback the release and go back to the old schema. While I know that I could take care of this via triggers, I'm looking for a code-only solution because triggers have a nasty habit of flying under the radar.

Is there anyone out there who can tell me a way to convince hibernate to hit both columns?

A very contrived example of my classes is:

@Entity
@Table(name = "superclass")
@Inheritance(strategy = InheritanceType.JOINED)
public class SuperClass {

    @Id @Generated
    Long id;
    boolean duplicate;
}

@Entity
@Table(name = "subclass")
public class SubClass extends SuperClass {
    String otherProperty;
}

With the tables to match:

CREATE TABLE superclass (
    id INT PRIMARY KEY AUTO_INCREMENT,
    duplicate BOOLEAN
);

CREATE TABLE subclass (
    id INT NOT NULL,
    duplicate BOOLEAN,
    otherProperty VARCHAR(255),
    FOREIGN KEY (id) REFERENCES superclass(id)
);

When inserting a new SubClass entity, the duplicate column on the subclass table will be NULL.

Thanks a bunch!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

云胡 2024-11-14 21:33:34

在代码中定义两个属性,将一个属性映射到每一列,然后在代码中保持它们同步怎么样?一种是实物财产,一种是影子财产。它并不漂亮,但它应该仅限于一个类(或一个类及其超类)的实现。

当您能够删除列时,您可以删除阴影属性。

How about defining two properties in your code, mapping one to each column, then keeping them in sync in the code? One is the real property, and one is a sort of shadow property. It's not pretty, but it should be confined to the implementation of one class (or one class and its superclass).

When you are able to drop the column, you can remove the shadow property.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文