oracle 为什么 Hibernate 转而使用 LONG 而不是 CLOB？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3719905/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why has Hibernate switched to use LONG over CLOB?
提问by mindas
It looks like that Hibernate started using LONGdata type in version 3.5.5 (we upgraded from 3.2.7) instead of CLOBfor the property of type="text".
它看起来像Hibernate的使用开始LONG在3.5.5版本，而不是数据类型（从3.2.7升级）CLOB的财产type="text"。
This is causing problems as LONGdata type in Oracle is an old outdated data type (see http://www.orafaq.com/wiki/LONG) that shouldn't be used, and tables can't have more than one column having LONGas a data type.
这是造成问题，因为LONG在Oracle数据类型是一个古老的过时的数据类型（参见http://www.orafaq.com/wiki/LONG不应被使用），以及表不能具有一个以上的列LONG作为一种数据类型。
Does anyone know why this has been changed?
有谁知道为什么这已经改变了？
I have tried to set the Oracle SetBigStringTryClobproperty to true (as suggested in Hibernate > CLOB > Oracle :(), but that does not affect the data type mapping but only data transfer internals which are irrelevant to my case.
我试图将 OracleSetBigStringTryClob属性设置为 true（如Hibernate > CLOB > Oracle :(）中所建议的，但这不会影响数据类型映射，而只会影响与我的情况无关的数据传输内部。
One possible fix for this is to override the org.hibernate.dialect.Oracle9iDialect:
对此的一种可能解决方法是覆盖org.hibernate.dialect.Oracle9iDialect：
public class Oracle9iDialectFix extends Oracle9iDialect {
public Oracle9iDialectFix() {
super();
registerColumnType(Types.LONGVARCHAR, "clob");
registerColumnType(Types.LONGNVARCHAR, "clob");
}
}
However this is the last resort - overriding this class is step closer to forking Hibernate which I would rather avoid doing.
然而，这是最后的手段——覆盖这个类离分叉 Hibernate 更近了一步，我宁愿避免这样做。
Can anybody explain why this was done? Should this be raised as a bug?
任何人都可以解释为什么这样做？这应该作为错误提出吗？
[UPDATE]: I have created https://hibernate.atlassian.net/browse/HHH-5569, let's see what happens.
[更新]：我已经创建了https://hibernate.atlassian.net/browse/HHH-5569，让我们看看会发生什么。
采纳答案by mindas
It looks like the resolution to this issue is to use materialized_clob, at least that's what's being said by Gail Badner on HHH-5569.
看起来这个问题的解决方案是使用materialized_clob，至少 Gail Badner 在HHH-5569上是这么说的。
This doesn't help me at all (and I left relevant comment about that) but might be helpful for someone else here. Anyway the bug is rejected and there is very little I can do about it but use overriden dialect :(
这根本对我没有帮助（我留下了相关评论），但可能对这里的其他人有帮助。无论如何，这个错误被拒绝了，我对此无能为力，但使用覆盖方言:(
回答by Pascal Thivent
Can anybody explain why this was done? Should this be raised as a bug?
任何人都可以解释为什么这样做？这应该作为错误提出吗？
This has been done for HHH-3892- Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[](update of the documentation is tracked by HHH-4878).
这已针对HHH-3892 完成-改进了对将 SQL LONGVARCHAR 和 CLOB 映射到 Java String、SQL LONGVARBINARY 和 BLOB 到 Java byte[] 的支持（文档的更新由HHH-4878跟踪）。
And according to the same issue, the old behavior was wrong.
根据同样的问题，旧的行为是错误的。
(NOTE: currently, org.hibernate.type.TextType incorrectly maps "text" to java.sql.Types.CLOB; this will be fixed by this issue and updated in database dialects)
（注意：目前，org.hibernate.type.TextType 错误地将“文本”映射到 java.sql.Types.CLOB；这将通过此问题修复并在数据库方言中更新）
You can always raise an issue but in short, my understanding is that you should use type="clob"if you want to get the property mapped to a CLOB.
您总是可以提出问题，但简而言之，我的理解是，type="clob"如果要将属性映射到CLOB.
PS: Providing your own Dialectand declaring it in your Hibernate configuration (which has nothing to do with a fork) is IMHO not a solution on the long term.
PS：提供你自己的Dialect并在你的 Hibernate 配置中声明它（这与 fork 无关）是恕我直言不是长期的解决方案。
回答by Lukas Eder
I cannot answer your question about why, but for Hibernate 6, it seems they're considering switching back to using CLOB
我无法回答你关于为什么的问题，但对于 Hibernate 6，他们似乎正在考虑改用CLOB
