正巧收到了trae的solo比赛信息，下午就把开发模式改为了solo模式试试。但是先吐槽一点，solo模式下就没有聊天和builder之分了，我想聊天的需求就得不到满足了，我的办法是在每句话的后面都加一句暂停。虽然麻烦一点，但是好用。另外，转变之后的一个变化是编辑器和聊天框对调了位置。现在聊天框在左边了。除了这个以外还没有发现什么不一样的，慢慢体会一下。发现一个问题。就是切换了这个模式之后，之前已经解决的问题，现在又出现了，这块智能再重新教学一下。
今天真的收获很大，问题逐渐发现了。以下是珊根据我们的排查过程总结的结果，记录下来以后可以参考。
问题分析总结
**根本原因**
`sys_config` 是金仓数据库的**系统视图**（位于 `sys_catalog` schema），不是应用表：
```sql
CREATE OR REPLACE VIEW sys_catalog.sys_config AS
SELECT 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的方式，可能还要研究新的处理办法。这个可以后面重点关注一下。
奇怪，现在修改代码珊又开始编译很多包了？是什么原因呢？暂时先不考虑了，记个备忘吧，明天有空的时候再解决。