看起来 Hibernate 在 3.5.5 版本（我们从 3.2.7 升级）中开始使用 LONG 数据类型，而不是 CLOB 来作为 type=" 的属性文本”。
这会导致问题，因为 Oracle 中的 LONG 数据类型是一种过时的旧数据类型（请参阅 http://www.orafaq.com/wiki/LONG），不应使用，并且表中不能有多个以 LONG 作为数据类型的列。
有谁知道为什么会这样改变？
我尝试将 Oracle SetBigStringTryClob 属性设置为 true （按照 Hibernate > CLOB 中的建议） > Oracle :()，但这不会影响数据类型映射，只会影响与我的情况无关的数据传输内部。
对此的一种可能的解决方法是覆盖 org.hibernate.dialect。 Oracle9iDialect：
public class Oracle9iDialectFix extends Oracle9iDialect {
public Oracle9iDialectFix() {
super();
registerColumnType(Types.LONGVARCHAR, "clob");
registerColumnType(Types.LONGNVARCHAR, "clob");
}
}
然而，这是最后的手段 - 重写这个类更接近分叉 Hibernate，我宁愿避免这样做，
任何人都可以解释为什么这样做吗？
这应该作为错误提出吗？
[更新]：我创建了 https://hibernate.atlassian.net/browse/HHH-5569 ，让我们看看会发生什么。
It looks like that Hibernate started using LONG data type in version 3.5.5 (we upgraded from 3.2.7) instead of CLOB for the property of type="text".
This is causing problems as LONG data 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 LONG as a data type.
Does anyone know why this has been changed?
I have tried to set the Oracle SetBigStringTryClob property 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.
One possible fix for this is to override the 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.
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.
发布评论
评论（3）
看起来这个问题的解决方案是使用
materialized_clob，至少 Gail Badner 在 HHH-5569。这对我根本没有帮助（我对此留下了相关评论），但可能对这里的其他人有帮助。不管怎样，这个错误被拒绝了，我对此无能为力，只能使用覆盖方言:(
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.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 :(
已针对 HHH-3892 完成此操作 - 改进对映射 SQL LONGVARCHAR 的支持和 CLOB 到 Java String，SQL LONGVARBINARY 和 BLOB 到 Java byte[] （文档的更新由 HHH-4878）。
根据同一个问题，旧的行为是错误的。
您可以随时提出问题，但总而言之，我的理解是，如果您想将属性映射到
CLOB，则应该使用type="clob"。PS：提供您自己的方言并在 Hibernate 配置中声明它（与分叉无关）恕我直言，从长远来看，这不是一个解决方案。
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).
And according to the same issue, the old behavior was wrong.
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 aCLOB.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.我无法回答你的问题，但对于 Hibernate 6，似乎 它们正在考虑切换回使用
CLOBI cannot answer your question about why, but for Hibernate 6, it seems they're considering switching back to using
CLOB