使用PostgreSql,当dev环境的数据库schema与sit环境不一致时,调用IDbAccessor.UpdateSql方法会报错 about efcore.sharding

[Coldairarrow]

为么测试环境和生产环境schema不一致，这不是给自己挖坑？

[NCrab1998]

为么测试环境和生产环境schema不一致，这不是给自己挖坑？

这不是 sit 环境跟 prd 环境一不一致的问题, 那只是我描述发现问题的过程
只是感觉这 schema 写死在 table 标签, 配置连接字符串的"Search Path"也没用, 不太好
而且查询方法是没问题的, 就这个 UpdateSql 要组装 SQL 的地方给报错了

[hkszlq]

为么测试环境和生产环境schema不一致，这不是给自己挖坑？

通常生产环境的Schema不会取名默认的Public.
假如Postgresql的Schema是“Other”,希望从Postgresql的连接字符串比如Search Path="Othter",框架自动取得Schema:“Other”, UpdateSQL方法会使用Other.TABLCNMMA来执行语句

[Coldairarrow]

为什么测试环境不设为Othter?
并且标准连接字符串中并没有这个定义，https://www.connectionstrings.com/npgsql/
如果想自己定义，这不符合约定大于配置原则

[hkszlq]

为什么测试环境不设为Othter?
测试环境可以使用啊，重新改成'Other',重新编译即可，但如果将来生产环境改名或其他项目不用这个名字了岂不是要重新编译造成不便呀。
并且标准连接字符串中并没有这个定义，https://www.connectionstrings.com/npgsql/
有呀，参考：https://www.npgsql.org/doc/connection-string-parameters.html
Search Path | Sets the schema search path. 设置此值会拿到实际使用的schema
如果想自己定义，这不符合约定大于配置原则
这是客户安全部门的硬性要求不能使用默认schema名称，没办法啊

[Coldairarrow]

这个schema应该是按照业务划分的，在数据库设计的时候就应该定下来，而不是说可以随便改变的东西
只要代码是同一份，那么数据库就应该是一样的结构

[hkszlq]

这个schema应该是按照业务划分的，在数据库设计的时候就应该定下来，而不是说可以随便改变的东西
只要代码是同一份，那么数据库就应该是一样的结构

对的，一般定下来就不会改的，只是如果您的框架能通过更改配置自适应Schema那就更加完美了。

[Coldairarrow]

做都能做，但是没必要做，如果仅仅为了支持这种特殊场景而去自定义一个配置项，意义不大
所以不考虑

[hkszlq]

做都能做，但是没必要做，如果仅仅为了支持这种特殊场景而去自定义一个配置项，意义不大
所以不考虑

了解。