弃用后实现 Hibernate UserType 的最佳方法？
我最近获得了最新版本的 Hibernate，并注意到我的 UserTypes 现在有关于 AbstractStandardBasicType 的 nullSafeGet(ResultSet,String) 和 nullSafeSet(PreparedStatement,T,int) 方法 已弃用，转而采用采用SessionImplementor 参数。问题是，当您实现 UserType 时，SessionImplementor 不会像 BasicType、CompositeUserType 等中那样传递给您。
我检查了 Hibernate 手册以查看是否有更新的示例。他们的 UserType 示例使用 get/set 而不是 nullSafeGet/nullSafeSet，但这些方法也已被弃用，取而代之的是采用 SessionImplementor 的版本。因此，似乎 Hibernate 的官方 UserType 示例也在使用已弃用的方法，这让我想知道两件事：
- 是否有一种从 UserType 中获取 SessionImplementor 的好方法？
- 如果从 UserType 中获取 SessionImplementor 不切实际，并且我不想编写自己的 nullSafeGet/nullSafeSet，我是否应该放弃 UserType 而转而使用其替代方案之一？ UserType 和 BasicType 之间有哪些实际区别？
I recently got the latest version of Hibernate and noticed that my UserTypes now have warnings about AbstractStandardBasicType's nullSafeGet(ResultSet,String) and nullSafeSet(PreparedStatement,T,int) methods being deprecated in favor of their corresponding methods that take a SessionImplementor argument. The problem is that when you implement a UserType, the SessionImplementor doesn't get passed to you the way that is does in BasicType, CompositeUserType, etc.
I checked the Hibernate manual to see if there was an updated example. Their UserType example uses get/set instead of nullSafeGet/nullSafeSet, but those methods were also deprecated in favor of versions that take a SessionImplementor. So, it seems like even Hibernate's official UserType example is using deprecated methods, which leads me to wonder two things:
- Is there a good way to get the SessionImplementor from within the UserType?
- If it isn't practical to get the SessionImplementor from within UserType, and I don't want to write my own nullSafeGet/nullSafeSet, should I abandon UserType in favor of one of its alternatives? What are the practical differences between UserType and, for example, BasicType?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
感谢 Ryan Ransford 对我最初问题的评论。虽然这并不是真正解决问题的方法，但他从Hibernate 开发人员邮件列表解释了为什么没有可用的解决方案。
考虑到这些只是弃用警告，因此在下一个非维护版本可用时将过时的解决方法上投入太多时间是没有意义的。不幸的是，下一个大版本是 4.0，而不是 3.7，因此迁移可能会涉及更多一些。
Thanks to Ryan Ransford for his comment on my original question. Although it's not really a solution to the problem, the link he provided from the Hibernate developers mailing list explains why no solution is available.
Considering that these are just deprecation warnings, it doesn't make sense to invest too much time in a workaround that will be obsolete when the next non-maintenance release is available. Unfortunately, the next big release is 4.0, not 3.7, so migrating might be a little more involved.