|
锁定老帖子 主题：一个无奈的Hibernate问题
精华帖 (3) :: 良好帖 (0) :: 新手帖 (10) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-09-24
greenhunter 写道 lgdlgd 写道 这个问题我遇到过，确实都是CharacterType这个类惹的祸，初步看到，HIBERNATE从JDBC取得数据库字段类型，判断如果是CHAR（具体代码好像是12，记不得了），就使用以上的那个类CharacterType来处理，然后这个类直接取第一位，也不管数据库是CHAR(1) 还是CHAR(n)，我觉得这是明显有问题的，不知道是不是有什么特殊的原因，不过我使用处理String类型的那个类替换了这个类，到现在快一年了，没发现有什么不妥。
这个问题刚刚遇到，呵呵，支持lgdlgd 的解决方法 说一句对JE上各位看官的感觉。请详细看明白提问者要描述的问题，同样一个问题，不同的人看到的东西大相径庭。 就这个问题来说，你可以认为楼主我Hibernate用的不好，评个新手；同样，也可以认真思考，像楼上的这位一样有所收获..总的来说，希望大家都有收获吧 |
| 返回顶楼 | |
|
发表时间：2009-09-25
-"不过我使用处理String类型的那个类替换了这个类"，没太明白这句话的意思？ 是改了Hibernate的源码？还是？能说具体点做法么？ -Hibernate也是封装了JDBC，RS到POJO的映射应该很好做； -因为LZ是无法确定哪个字段是否是CHAR(N)类型的，所以我想Trim()方法应该不适用；不可能每个返回列都Trim()吧？ |
| 返回顶楼 | |
|
发表时间：2009-09-25
C_J 写道 -"不过我使用处理String类型的那个类替换了这个类"，没太明白这句话的意思？ 是改了Hibernate的源码？还是？能说具体点做法么？ -Hibernate也是封装了JDBC，RS到POJO的映射应该很好做； -因为LZ是无法确定哪个字段是否是CHAR(N)类型的，所以我想Trim()方法应该不适用；不可能每个返回列都Trim()吧？ 相当于改了源码，做法是把处理String的那个类COPY出来，名字和包改成ChacratorType一样，然后并不放回到Hibernate的JAR包，只放在自已的工程中， 其实不只是类似BUG需要这样处理，还有一些不满足需求的框架也需要这样复盖一下，所以我的应用中会有别的开源项目的包，这样正好哪天把Hibernate版本升级了，而且它没把这BUG处理掉的时候，我的代码也不受影响。 -因为LZ是无法确定哪个字段是否是CHAR(N)类型的，所以我想Trim()方法应该不适用；不可能每个返回列都Trim()吧？ 这个分析得应该很对。 |
| 返回顶楼 | |
|
发表时间：2009-09-25
C_J 写道 -"不过我使用处理String类型的那个类替换了这个类"，没太明白这句话的意思？ 是改了Hibernate的源码？还是？能说具体点做法么？ -Hibernate也是封装了JDBC，RS到POJO的映射应该很好做； -因为LZ是无法确定哪个字段是否是CHAR(N)类型的，所以我想Trim()方法应该不适用；不可能每个返回列都Trim()吧？ 漏了一点，除了名字和和路径，代码也有改，这个比较简单，不细说了 |
| 返回顶楼 | |
