最近我们公司的一个"大型"系统上线。
为了图方便,为了与老系统的id区分,直接将这个id由原来的9位升到了12位.

估计经理忘了或者经验不足,通知了客户,并没有通知作下游系统主管的我这边.
自认为很通技术的客户一番测试,给了ok没问题的回复.

于是过了几天,客户发现,与我这边有接口的各种外围统系(主要是银行)无法成功调用了,而且只有这些新统进来的数据无法调,老的数据是ok的.

他们 tpcall 就挂住，而我这边可以看到报错：

奇怪的是，用我们自己的测试 client 来调是正常的。

只能认定是做为银行的调用端有问题，甚至还以为是 txuedo 的 bug 又出现了(确实有这个bug,报错也是一样的).
反复折腾.

最后一一比较新老数据,我终于发现,作为接口传输参数的这个id怎么新的变得这么长. 12 位!!!
蛋疼阿,因为我接手前,脑残的前辈和银行对接口的时候,定义 fml32 将这个 id 用了 long 型.

而同样不靠谱的银行端口,用的是32位的windows来开发的系统.
12位还想塞到 long 里面去? 银行的 tuxedo 那边连 buffer 都收不下来.
而我这边全部是64位的AIX,自然一点问题也没有.

而将接口改为 string 也是不现实的. 一但我这边一改,所有调用端都得动.
先不说一一通知10多家银行和各种接口是否现实, 就算接口改为 string 了,天知道银行自己内部的程序,是否有将这个id取下来,然后拿个 long 型变量的情况.  有些银行连开发人员和源代码都没了.

让他们升级为64位,更不可能了.
最悲剧的是,我们不占理阿,谁让一开始就用 long 来做接口,用 string 不就万事大吉了.你自己拿 long 又去存,存不存得下那是你的问题了.
以后切记凡涉及接口,一律用 string

各大领导开会,讨论,折腾.....
最后一检查9位段的资源,还有几辈子都用不完的资源没用.
解决方案就是改回9位.

数据库里那些已有的 id 也得 update , 系统复杂的模型阿,还有外键约束.....
于是我国庆也得悲剧的加班来写 update 的方案和脚本了。

--转自搜狗