金仓老旧项目改造-5

正巧收到了trae的solo比赛信息下午就把开发模式改为了solo模式试试。但是先吐槽一点solo模式下就没有聊天和builder之分了我想聊天的需求就得不到满足了我的办法是在每句话的后面都加一句暂停。虽然麻烦一点但是好用。另外转变之后的一个变化是编辑器和聊天框对调了位置。现在聊天框在左边了。除了这个以外还没有发现什么不一样的慢慢体会一下。发现一个问题。就是切换了这个模式之后之前已经解决的问题现在又出现了这块智能再重新教学一下。今天真的收获很大问题逐渐发现了。以下是珊根据我们的排查过程总结的结果记录下来以后可以参考。## 问题分析总结### **根本原因**sys_config 是金仓数据库的**系统视图**位于 sys_catalog schema不是应用表sqlCREATE OR REPLACE VIEW sys_catalog.sys_config ASSELECT pg_config.name, pg_config.setting FROM pg_config;### **问题机制**- 应用查询 sys_config 时由于 **search_path** 包含系统 schema- 数据库找到了 sys_catalog.sys_config 系统视图- 该视图只有 name/setting 字段缺少应用需要的 config_code 等字段- 导致配置初始化失败### **关键启示**- 金仓/PostgreSQL 中同名对象可能存在于不同 schema- 系统视图 vs 应用表容易造成混淆- **始终显式指定 schema** 是最佳实践感觉这个是我们这次改造遇到的第一个卡点并且非常隐蔽如果不是珊真的很难发现这个问题卡了两天我觉得是记录blog的一个最关键的点今天运气不错。很好很开心。另外还了解了spring.factories的机制可以通过他把applicationlisttener都注册进来在程序启动的时候运行后面如果有问题不知道什么原因的时候也可以从factories这块尝试一下是否有解决的思路。程序员不就应该开开心心的跟代码沟通吗为什么现在的公司都在扯皮呢。刚刚插进来一个会很无聊又是谈需求说了半天大家没有一个人具体说需求是什么都是在重复领导说过的话一遍遍的重复。然后会议就结束了接下来就是下一个循环再下一次会的时候再继续重复这个模式直到最后实在不行了然后随便应付一下项目交付就完了。无限的循环这就是外行指导内行的悲哀呀。也是现在行业的现状。有了ai并不能避免这种现象反而会使这种现象更加严重。算了这些政治话题就不讲了还是继续工作吧。修改了配置之后还是不好使看来信息的优先级要高于currentSchema中的指定。还是老老实实在sql上添加吧但是这两个隐患一个是这个代码的修改可能会影响mysql版本但是我马上确认了一下这个忧虑是多余的因为这个类就已经加上了kingbase的前缀所以只对金仓有效另一个就是有可能在其它sql中也会有类似的问题并且这个地方用的是原始sql的方式其它地方如果是用的mybatisplus的方式可能还要研究新的处理办法。这个可以后面重点关注一下。奇怪现在修改代码珊又开始编译很多包了是什么原因呢暂时先不考虑了记个备忘吧明天有空的时候再解决。