YiAng603
YiAng603
您好，若无特殊需求，建议考虑dm数据库配置大小写不敏感；若有大小写敏感需求，您可自行扩展适配dm。
您好，可以参考这个 https://github.com/secretflow/scql/issues/523
https://github.com/secretflow/secretnote/issues/53 用这个组合试试？
您好，我这边正好有个all in one的环境，您把配置也发一下？我试一下。 我看您发了1个csv，双方用的同一份数据？
刚下载您的数据看了一下，因为您的数据中有个, 不符合csv的RFC 4180标准。 详见：
快速测试的话，建议把,去掉，或者换成其他符号，我们在all in one 1.11测试了，有,确实是不可以的。
您好，目前开源版本的更新节奏总体较慢，周期视具体的需求情况规划，目前暂无pad的更新规划，您可以持续关注社区，也欢迎您一起共建，贡献自己的力量。
您好，可参考：https://www.secretflow.org.cn/zh-CN/docs/secretpad-all-in-one/v1.11.0b1/p2p_deploy/model_deployment#step3
您好，若可以通过API接口进行查询，是否有权限通过API删除？ 作为生产环境，操作要谨慎，对于not ready node是否可容忍呢？已经not ready的node，对kuscia、dp、sf等暂无影响。
是的，这是k8s的机制，对于not ready状态的机器，pod不会调度上去。 对于kuscia内的k8s来说，取的 Kuscia 的 hostname 作为 K3s 的节点名，kuscia重启后，podname发生了变化，所以老的kuscia node就会显示not ready，同时新的dp会调度在新的kuscia node，执行sf、scql等任务时，也会调度在新的kuscia node。