在Hibernate中建模时间型关系表

您说没有更新任何行,但听起来您正在更新该行的is_current列。我只需要使用hibernate(更新行的iscurrent字段,然后创建一个新行)做同样的事情,而不是尝试编写一个实际上是更新的自定义删除函数。

row1.setCurrent(false);
session.saveOrUpdate(row1);
row2 = new Row(row1); //Copy constructor; use a different primary key (or your default primary key for a new object)
row2.setCurrent(true);
row2.setFoo("bar"); //whatever data updates you are doing for the new row
session.saveOrUpdate(row2);

您可以将此过程包装在一些中间层/业务逻辑代码中,以确保不会更新其他字段。

我们有一个与Hibernate一起使用的完全时间星模式。然而,Hibernate从不知道审计或事实表,只知道表的视图。这允许我们像往常一样使用Hibernate,所以当Hibernate对DB中的视图发出插入、删除或更新时,将为这些相应的任务触发“而不是”触发器。

因此,在您的例子中,创建一个视图(Hibernate不知道任何更好的情况,并且是完全透明的)和适当的触发器来设置标志和其他内容。事实上,我很惊讶我们是如何以相对较少的痛苦摆脱这种困境的——我们的设计真的可以更好,因为使用Hibernate是一个事后诸葛亮/附加组件。

经过进一步的研究,我相信没有一种简单的方法可以做到这一点。我想尝试的一种方法是将原始表隐藏在可更新的视图后面,这样Hibernate可以呈现出一些看起来正常的东西,而视图上的触发器将简单的CRUD操作映射到底层表中所需的操作序列。

但是,我怀疑这可能不会太好地工作,因为我相信Hibernate在任何时间点都会维护自己对数据库内容的概念;例如,如果我删除一个实体,Hibernate的缓存会认为物理行不再存在于表中(虽然它确实存在,但现在为假)。如果这种不匹配可能导致最坏情况下的数据一致性问题,或者可能导致无效的批优化,我不会感到惊讶。

不管怎样,现有的表都是可怕的,所以在这种变化的背景下使它们更加健全是我将采用的方法。至少这个评估阶段已经使现有模型的一些缺陷更加清晰。