前言: 之前碰到了一个界面上分页失效的问题,并为之困扰了数日,后台定位为排序失效的问题,问题就迎刃而解了... 问题描述: 在界面上的某个分页功能存在失效的问题,第一页、第二页和最后一页的分页效果正常,但是中间的分页数据不变。 QA提了一个关于此的
前言: 之前碰到了一个界面上分页失效的问题,并为之困扰了数日,后台定位为排序失效的问题,问题就迎刃而解了...
问题描述:
在界面上的某个分页功能存在失效的问题,第一页、第二页和最后一页的分页效果正常,但是中间的分页数据不变。 QA提了一个关于此的Bug.
问题分析:
1. 分析界面分页代码
界面分页的代码属于在项目使用较多的组件,关于失效分页部分的代码无特殊的定制和使用。
2. 前端和后台端交互的分析
基于HTTP的监控工具,发现分页请求的请求数据一切正常,分页的start/limit数据正确,过滤条件是正确的,排除前端问题。
3. 后台的代码分析
后台的代码是基于Hibernate实现的DAO查询分析,代码基于基类的常规查询,无特殊代码存在。而且这些基类的常规查询被项目中不同的模块所使用,其他模块功能正常。
故对这些查询的代码是否存在问题,持怀疑态度。
4. 怀疑生成的SQL是否存在问题
打印出在查询中使用的SQL语句,经过分析,SQL也不存在问题。其中使用了log4jdbc来监控sql执行。
5. 基于查询中使用的SQL在Oracle的plsql中直接运行SQL
结果发现,在50~75, 75-~100等区间,的确查询数据不变。 SQL语句:
select *
from (select row_.*, rownum rownum_
from (select this_.id as id25_0_,
this_.create_time as create2_25_0_,
this_.creator as creator25_0_,
this_.modify_time as modify4_25_0_,
this_.updater as updater25_0_,
this_.version as version25_0_,
this_.bank_id as bank7_25_0_,
this_.bank_name as bank8_25_0_,
this_.chk_comment as chk9_25_0_,
this_.chk_status as chk10_25_0_,
this_.cup_bank_id as cup11_25_0_,
this_.del_status as del12_25_0_,
this_.smp_name as smp13_25_0_,
this_.status as status25_0_
from ns_para_bank this_
where this_.chk_status = '02'
and this_.chk_status = '02'
and this_.del_status = '01'
order by this_.modify_time desc
) row_
where rownum <= 100)
where rownum_ > 75
6. 后怀疑是排序字段modifyTime问题
经过排查,发现大部分的modifiedTime字段的数据为空,故导致了排序失效;由于排序失效,引发了分页数据不变的问题
问题的解决
为排序条件新增了一个排序字段, 在modified_time失效的情况下,保证整体排序的有效性,即可解决分页失效问题。
本文原创发布php中文网,转载请注明出处,感谢您的尊重!