根据 data_id 匹配配置文件类型

bestK commented 2 months ago

...
impl SetConfigReq {
    pub fn new(config_key: ConfigKey, value: Arc<String>) -> Self {
        let data_id_clone = Arc::clone(&config_key.data_id);
        Self {
            config_key,
            value,
            op_user: None,
            config_type: Self::detect_config_type(data_id_clone),
            desc: None,
        }
    }

    fn detect_config_type(data_id: Arc<String>) -> Option<Arc<String>> {
        if let Some(pos) = data_id.rfind('.') {
            let suffix = &data_id[pos+1..];

            if !suffix.is_empty() {
                return Some(ConfigType::new_by_value(suffix).get_value());
            }
        }

        None
    }
...

导入配置文件时，根据配置文件名(data_id)后缀调用 get_value 映射 config_type,实现初始化配置格式 https://github.com/nacos-group/r-nacos/blob/03d84e963eab7603b3dd23b7849b86c501c22ae9/src/config/config_type.rs#L55-L65

CLAassistant commented 2 months ago

All committers have signed the CLA.

heqingpan commented 2 months ago

这个逻辑一般场景可能没问题的，不过有几个点要考虑：

通过data_id取的config_type 和api明确指定的config_type如果冲突该如何处置？
data_id创建之后是不变的，如果能过data_id后置设置类型，是不是只要在第一次时才根据data_id初始化config_type? （这样还刚好能比较好解决第1点问题）

bestK commented 2 months ago

这个逻辑一般场景可能没问题的，不过有几个点要考虑：

通过data_id取的config_type 和api明确指定的config_type如果冲突该如何处置？

data_id创建之后是不变的，如果能过data_id后置设置类型，是不是只要在第一次时才根据data_id初始化config_type? （这样还刚好能比较好解决第1点问题）

确实是这样的，我再改改

edit:

好像不对啊，新增跟修改的接口都是调用的 add_config

http://127.0.0.1:10848/rnacos/api/console/v2/config/add http://127.0.0.1:10848/rnacos/api/console/v2/config/update

在这个函数里面，即使使用 SetConfigReq::new(config_key, content) 设置里面的 config_type,也会被后面的 req.config_type = param.config_type; 重新赋值, https://github.com/nacos-group/r-nacos/blob/03d84e963eab7603b3dd23b7849b86c501c22ae9/src/console/v2/config_api.rs#L98-L121

我这个 pr 初心是针对导入配置文件时根据后缀设置 config_type 的，并不影响原本的新增修改逻辑

heqingpan commented 2 months ago

如果只想针对导入场景，可以考虑在导入的api入口层增加类型设置。

bestK commented 2 months ago

改了 ,另外我发现前端好像有bug,在登录态失效进行上传时也会提示上传成功然后再重定向到登录页

heqingpan commented 2 months ago

我晚上回去验证一下，没什么问题就接受pr。

前端的问题，我后面回去抽空看看。

bestK commented 2 months ago

前端的我看了，错误是为 handlerUploadFinsh 只判断了 code 等于 200，没有像 axios 拦截器那样判断 no-login ,我在想是不是可以把

HttpResponse::Ok() // 换成 Unauthorized()
                        .insert_header(("No-Login", "1"))
                        .json(ApiResultOld::<()>::error("NO_LOGIN".to_owned(), None))
                        .map_into_right_body()

返回401

然后前端

截止目前发现好像不走这个拦截器，是个 Uncaught (in promise)

heqingpan commented 2 months ago

后端应该有统一的拦截吧？

前端的可能要注意一下版本，目前r-nacos使用的是前端0.3.x分支，不是前端的master 分支。

前端的master分支代码结构做了较大重构，目前没有完全验证通过。

所以前端的小问题可能要先放放比较合适😂

bestK commented 2 months ago

我之前搞错了，如果 httpStatus = 401 要在 error 回调里面处理

上传组件

        <n-upload
          :action="apis.configImport"
          :headers="uploadHeader"
          :show-file-list="false"
          @before-upload="doBeforeUpload"
          @finish="handlerUploadFinish"
          :custom-request="customRequest" // 可能需要使用 custom-request 属性才能走 axios 的统一响应拦截
          v-if="webResources.canUpdateConfig"
        >

那就先这样吧前端不整了

nacos-group / r-nacos

根据 data_id 匹配配置文件类型 #105