ClearQuest缺陷之BaseAction

      在Schema设计中，我们经常把一些公用的代码写入Base Action的hook，这样可以减少我们的工作量与Schema的复杂性。然而，ClearQuest关于Base Action的设计并不完善，BaseAction的hook只能先于顶层Action运行，而不能晚于顶层Action的hook运行，这种缺失导致有时候无法利用BaseAction的便利。下面结合具体的经历说一下这种缺失带来的不便。

 

      我们的Schema中主Entity叫Issue，通过一种叫Change_Log的Entity来记录字段的改动，所有这些改动都记录在Issue的Reference List类型字段log中。Schema中的逻辑是这样，在Base Action的Validation hook中检测Issue字段的变动，并根据这些变动生成相应的Change_Log并添加到Issue的字段log。其他Action的Validation hook中也有逻辑代码，这些代码有时会导致Issue的提交失败。于是，问题就出来了，CQ中经常出现没有被关联到Issue上的Change_Log，即没有实际意义的log。这些log是这样产生的：首先，对Issue的修改通过了Base Action的验证并执行了生成Change_Log的代码，接着执行外层Action的Validation hook，如果外层hook验证失败且用户撤销了这次改动，那么对Issue字段的改动也会被撤销，先前生成的Change_Log也就失去了意义，但是这些无意义的log却遗留在了CQ中。

 

      然而很多应用都依赖Issue的Change_Log，由于无意义log的存在，我们的脚本不得不从Issue来查询log，因为直接从Change_Log查询会不可避免的抓到脏数据（无意义的log）。但是从Issue查询log效率低下，尤其是哪些数据量庞大的CQ，与直接从Change_Log查询相比效率下降的非常明显，甚至不可接受。

 

      意识到这种问题后我们开始设法避免这种无意义的log产生，提高CQ的效率。开始想到用Commit hook，然而Validation hook是最后一次修改Entity的机会，Commit hook不允许再修改Entity，而我们的Change_Log还必须关联到Issue上，所以用Base Action的Commit hook无法解决这个问题。后来将记录log的代码从Base Action移到外层Action的Validation hook中，即每一个外层Action的Validation hook中都把记录log的代码重写一遍，才避免了无意义的log的产生。

 

      如果ClearQuest有在外层Action执行完之后才执行的Base Action，那么像无意义log这种问题就很容易解决了。遗憾的是ClearQuest没有提供这样的功能，我们不得不曲线处理。