Home  >  Article  >  Database  >  一个NHibernate的BUG

一个NHibernate的BUG

WBOY
WBOYOriginal
2016-06-07 16:12:421181browse

一、背景 我们现在做的项目,用NHibernate实现数据访问层。 访问数据时,有的数据库表是确定的:有明确的表名、字段名。这时候按照常规的方法处理即可:建立数据库表到类的映射,使用HQL读写数据库。 但有的数据访问,所针对的数据库表是不确定的,在运行阶

一、背景

我们现在做的项目,用NHibernate实现数据访问层。

访问数据时,有的数据库表是确定的:有明确的表名、字段名。这时候按照常规的方法处理即可:建立数据库表到类的映射,使用HQL读写数据库。

但有的数据访问,所针对的数据库表是不确定的,在运行阶段确定访问哪些数据库表的哪些字段。数据库表和字段都不确定,自然没办法建议O-R映射,只好构造SQL语句了。

既然已经用了NHibernate,我们利用SQL访问数据库时,也仍然使用NHibernate。主要是想利用它管理的Session,还有对分页查询的支持:可以指定开始行,还有所需要的总行数。

就因为贪这个便宜,出问题了。

二、错误

使用SQL(而不是HQL)访问数据库,而且加上访问范围(开始行或总行数),有时候会出现奇怪的问题:有的字段,在数据库中明明有值,但就是读不出来。

例如,有一个数据库表,表的定义大致是:MyTable(Id, Name, FromPoint)。

现在需要查询其中的前10条记录,利用下面的SQL语句:

select Id, Name, FromPoint from MyTable

创建好SQL查询后,设置查询范围:

...
var query = session.CreateSQLQuery(sql);
query.SetFirstResult(0);
query.SetMaxResults(10);
...

对于执行结果,期望的是,每条记录有三个字段。但实际上,只返回前两个字段的值,第三个字段,FromPoint的值,没有返回。

查看NHibernate的日志,所生成的SQL是:

select Id, Name from (select Id, Name, FromPoint from MyTable) where rownum<=10

这实在令人费解。

三、原因

在网上搜索,找不到原因。只好祭出最后的杀手锏:跟踪源代码。

结论是:NHibernate在解析SQL语句时有问题,导致过滤掉了不该过滤掉的列。

具体地说,在类 NHibernate.Dialect.Dialect的方法 ExtractColumnOrAliasNames 中有如下代码:

if (token.StartsWithCaseInsensitive("select"))
	continue;
if (token.StartsWithCaseInsensitive("distinct"))
	continue;
if (token.StartsWithCaseInsensitive(","))
	continue;
if (token.StartsWithCaseInsensitive("from"))
	break;

这段代码的本意,是不将select、distinct等SQL保留字作为列,而且一旦遇到from保留字,就意味着列结束。

问题在于,它用了StartsWith,而不是整词判断,从而误伤了以这些关键字开头的字段。而且一旦有以from开始的字段,后面的字段都被过滤掉了。

四、办法

出问题的方法 ExtractColumnOrAliasNames 是 static internal 的,没有修改机会。我们只好绕道走:自行加上rownum的过滤条件。

本来要借助NHibernate实现跨数据库,我还一直告诫小伙伴们避免使用Oracle、SQL Server等数据库管理系统特定的SQL语法来着。

不少程序员会本能地想到一个解决方法:既然是开源的,而且错误原因找到了,拿过来修改好,编译一个新版本用就OK。我对此明确表示不赞成,一方面,这会脱离NHibernate主线版本的发展,另一方面,也给组件的引用带来不便:我们正在用Spring.NET管理NHibernate,build一个自己的版本,要设置一堆元信息,想想就头大。

五、范围

就我目前所知,该BUG出现的情景如下:

使用原生SQL访问数据库;设置了FirstResult、MaxResults等查询结果范围;最早的引入版本不详,最新的版本中,从源代码上判断,此问题仍然存在;我们使用的是Oracle数据库,其它数据库管理系统不详。 
Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn