Envers 如何处理架构更改？
我正在考虑从自行实现的版本控制解决方案切换到 Hibernate Envers，但我还不太确定。我已经阅读了很多相关内容，但我担心架构更改以及 Envers 在根据旧架构对数据进行历史记录后如何处理它们。
在这方面您对恩弗斯有何看法？您如何使用 Envers 处理架构更改和现有数据？
更新 1：
这不仅仅是添加从表中删除简单的列，而是例如将简单的 Forein-Key-Relationship 更改为具有两个 1:n-关系的单独实体（带有属性列的 M2M）。这是一个“逻辑”当使用 Envers 时，如果已经有根据旧模型的历史数据，是否有替代方法来手动编写 sql 脚本并将其传输到新的表示中？
I am thinking about switching from a self-implemented versioning-solution to Hibernate Envers, but I am not quite sure yet. I have read a lot about it, but I am concerned about schema changes and how Envers deals with them after having historized data according to an older schema.
What is your experience with Envers in this regard? How do you deal with schema changes and existing data with Envers?
Update 1:
It is not just about adding removing simple columns from a table, but e.g. when changing a simple Forein-Key-Relationship into a separate entity with two 1:n-relationships (M2M with attributed columns. This is a "logical" change in your data model. How do you deal with that when using Envers, when there is already historized data according to the old model? Is there an alternative to manually write sql-scripts and transfering them into the new representation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据我的经验，Envers 只是将实体表中的每个字段复制到其审计表中。审计表中复制的字段没有任何约束，包括可为空性和外键约束，因此在真实表上添加或删除此类约束没有问题。您添加到实体的任何类型的关系都只是在 Envers 下添加的新审计列和/或表，并且由您在其历史上下文中正确解释它们。
对于您的示例，如果我理解正确，从基于连接列的关系切换到基于连接表的关系，您只需让旧的连接列与连接表共存，并且在切换点，前者将不再被填充，而有利于后者。您的历史记录将被完全保留，包括您进行此切换的事实。如果您希望所有旧数据都适合审计表中的新模型，则由您来进行迁移。
In my experience, Envers simply copies every field from your entity table to its audit tables. The copied fields in the audit tables have no constraints on them, including nullability and foreign key constraints, so there's no problem with adding or removing such constraints on the real tables. Any kind of relationships you add to your entities will just be new audit columns and/or tables added under Envers, and it's up to you to correctly interpret them in their historical context.
For your example, if I understand correctly, of switching from a join-column-based relationship to a join-table-based one, you'd simply have the old join column coexisting with the join table, and at the point of the cutover, the former will cease being populated in favor of the latter. Your history will be completely preserved, including the fact that you made this switch. If you want all the old data to fit into the new model in the audit tables, it's up to you to do the migration.
修改现有架构应该不会有问题，因为 Envers 依赖您的 @Entities 来创建审核表。因此，如果您从现有表中添加或删除列，只要此更改反映在您的 @Entity / @Audited JavaBean 中，就应该没问题。
There shouldn't be problems with modifying the existing schema as Envers relies on your @Entities to create the audit tables. So if you add or remove a column from an existing table, as long as this change is reflected in your @Entity / @Audited JavaBean, it should be ok.
Envers 的外键重构应该没问题。由于 Envers 即使是一对多关系也创建了一个连接表，因此应该直接将其更改为多对多关系。我从官方文档中摘录了一段话：
The foreign key refactoring should be fine with Envers. As Envers creates a join table even for one-to-many relationship, it should be straight to change it to become many-to-many relationship. I extracted one paragraph from official document: