今天一大早就收到项目经理的邮件说用户管理的添加用户失败,让我赶紧查查原因,因系统整个权限控制部分是我设计的。当时脑子里第一反映就是难道上周刚上的版本对这块产生影响了??? 再想想不对,因新增和修改的部分都不触及权限模块的对象,更没对其逻辑代码做过任何改动啊! 不过本着“先查己”的原则,我还是赶紧做了下测试。
先进行功能测试,目的错误再现,页面提示有对象冲突错误。看来是实体化时的问题。
查系统错误日志文件,果然org.hibernate.exception.ConstraintViolationException,用户对象主键冲突。
这可奇怪了,在上周版本上线前,这个模块一直运行良好,现在怎么会出现这么个低级的冲突错误!!! 应用程序该模块的实体映射到业务逻辑都没做过变动啊~~~,所以数据库端的问题嫌疑很大!
一怒下,把测试库还原到以前的数据库版本再测试,一切ok! 现在问题可以锁定在数据库上了,数据库变更脚本做了什么坏事了。
二话不说调出上次的数据库更新脚本,一看~~~ 我真谢谢配置管理员了!
脚本上来就用DBCC CHECKIDENT给我来了个标识符重置,而且还是我权限模块两个关键表,一下全从0开始自增长! 实在不知道这位大哥是从什么角度考虑,要这么做的!
木办法要解决问题,强行把标识改回来吧:
DBCC CHECKIDENT (<tableName>,RESEED, <max+1>)
总结:对每种技术或命令,要只其理而用!
先进行功能测试,目的错误再现,页面提示有对象冲突错误。看来是实体化时的问题。
查系统错误日志文件,果然org.hibernate.exception.ConstraintViolationException,用户对象主键冲突。
这可奇怪了,在上周版本上线前,这个模块一直运行良好,现在怎么会出现这么个低级的冲突错误!!! 应用程序该模块的实体映射到业务逻辑都没做过变动啊~~~,所以数据库端的问题嫌疑很大!
一怒下,把测试库还原到以前的数据库版本再测试,一切ok! 现在问题可以锁定在数据库上了,数据库变更脚本做了什么坏事了。
二话不说调出上次的数据库更新脚本,一看~~~ 我真谢谢配置管理员了!
脚本上来就用DBCC CHECKIDENT给我来了个标识符重置,而且还是我权限模块两个关键表,一下全从0开始自增长! 实在不知道这位大哥是从什么角度考虑,要这么做的!
木办法要解决问题,强行把标识改回来吧:
DBCC CHECKIDENT (<tableName>,RESEED, <max+1>)
总结:对每种技术或命令,要只其理而用!