Hibernate - 使用唯一约束重命名对象
假设您有一堆带有“title”属性的 Article 对象。然后有一个带有 TITLE 列的 ARTICLE 表。 TITLE 列具有唯一约束。
用户界面在一页上显示所有文章，并带有一个用于编辑标题的文本字段。
想象一下这样的情况，您有两篇文章 X & Y、X具有标题“1”并且Y具有标题“2”。在该页面中，您将 Y 重命名为“2”，将 X 重命名为“1”，然后提交表单。将表单中的值直接复制到 hibernate 对象并保存后，将发生 ConstraintViolationException。
如果您从集合中删除一篇“1”文章，然后添加另一篇标题为“1”的文章并保存集合，也会发生这种情况。
那么处理这个 Hibernate 怪癖的最佳方法是什么？我觉得我应该重新安排用户界面或其他东西。在保存休眠对象之前手动检查这些条件似乎有点麻烦。
Say you have a bunch of Article objects, with a "title" property. Then there's an ARTICLE table with a TITLE column. The TITLE column has a unique constraint.
The UI shows all the articles on one page, with a text field for editing the title.
Imagine a situation where you have two articles X & Y, X having the title "1" and Y having the title "2". In the page, you rename Y to "2" and X to "1", then submit the form. With the values from the form copied directly to the hibernate objects and saved, a ConstraintViolationException will occur.
It also happens if you remove a "1" article from a collection, then add another article with the title "1" and save the collection.
So what is the best way to deal with this Hibernate quirk? I get the feeling I should rearrange the UI or something. Manually checking for these conditions before saving the hibernate objects seems a bit cumbersome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尽管我之前有过回答，但我确认排列两个持久实体的唯一字段会生成约束违规错误，即使您一次性执行此操作也是如此。
因此，我想说解决此问题的最简单方法是不允许任何可能意味着字段违反唯一约束的更改，即使最终结果有效。在 UI 层中编码应该相当简单。
为什么？
看来至少 MySQL 受到这个限制，因为我发现 here ，显然没有一种简单的方法可以解决这个问题而不造成严重的性能损失。
所以人们会认为这个问题可以很容易地通过编程来解决。是的，这会很糟糕，但是人们应该能够编写一些简单的代码来检查您的更新是否会排列两个现有的唯一字段，并分两步完成。
不过，它可能会变得毛茸茸的。想象一下排列 3 个实例而不是 2 个。例如，“A”、“B”、“C”变为“B”、“C”、“A”。三步？接下来怎么办？
Despite my previous answer, I confirmed that permutating unique fields of two persistent entities generates a constraint violation error even if you do it in one pass.
Therefore, I would say that the simplest way to solve this issue is by not allowing any changes that would imply a field violating a unique constraint, even if the final result would be valid. This should be fairly simple to code in the UI layer.
WHY?
It seems that at least MySQL is subject to this limitation, as I found here, and apparently there isn't a simple way to fix this without serious performance penalties.
So one would think that this issue could be easily solved programmatically. It would suck, yes, but one should probably be able to write some simple code to check if your update would permutate two existing unique fields, and do it in two steps.
It can get hairy, though. Imagine permutating 3 instances instead of two. For example, "A", "B", "C" becoming "B", "C", "A". Three steps? What next?
我的猜测是，您试图一次更新每个实例，从而实际上冲突了独特的属性。
查看
Session对象是否在每个查询之间关闭或刷新。在这种情况下，您必须在关闭/刷新之前更改两个实例。编辑：请确保您阅读我发布的下一个答案。
My guess is that you're trying to update each instance at a time, thus actually colliding the unique properties.
See if the
Sessionobject is being closed or flushed between each query. In this case, you'd have to change both instances before closing/flushing.EDIT: make sure you read the next answer I posted.