2.1.0版本，非 properties 格式的公共配置文件如yml的继承是否依然是在整个文件内容粒度进行，如果是请明确告知用户

[SSJSIAT]

• [Y] 我已经检查过discussions
• [Y] 我已经搜索过issues
• [Y] 我已经仔细检查过FAQ

描述bug
#3815
1.能够支持创建公共的 xml json yaml 等非 properties 格式 namespace，以及 Java 客户端能够以类似获取公共的 properties 格式的 namespace 的方法获取这些公共 namespace。
2.实现继承功能，因非 properties 格式本身不支持键值粒度的操作，继承将在整个文件内容粒度进行。
当前现象：非 properties 格式的公共配置文件，继承将在整个文件内容粒度进行。
（1）假设该公共配置文件有10个配置，如果继承该公共配置文件，继承只覆盖其中1个配置，那么公共配置文件中的其余配置均不会生效
（2）假设该公共配置文件有10个配置，如果继承该公共配置文件中的所有配置，再把继承的配置全部删除，公共配置文件的配置依然读取不到，类似#4777
在UI界面的描述中并没有让用户感知到这点，给用户带来问题和困扰

期望

如果非 properties 格式的公共配置文件，继承依然是在整个文件内容粒度进行，请明确告知用户，并将相关case也表示出来

额外的细节和日志

• 版本：2.1.0

[dosubot]

嗨，@SSJSIAT！很高兴再次看到你在这里提出问题。希望你今天过得不错！

根据我在Apollo仓库中的查找，Apollo在处理非properties格式配置文件（如yml）的继承时，确实是在整个文件内容粒度进行的。这是通过关联类型（继承类型）的Namespace实现的。关联类型的Namespace从公共类型的Namespace继承，并用于覆盖公共Namespace的某些配置。这种机制允许在粒度级别继承和覆盖配置，包括非properties格式文件，如XML，YAML，JSON等。

例如，如果公共Namespace有配置：

k1 = v1
k2 = v2

应用程序有一个关联类型的Namespace，它用新值v3覆盖配置项k1，那么该应用程序的有效配置将是：

k1 = v3
k2 = v2

这展示了Apollo如何支持在文件内容粒度级别继承和覆盖配置，包括非properties格式。你可以在Apollo核心概念 - Namespace中找到更多信息。

关于Apollo 2.1.0版本和最新版本2.2.0在处理非properties格式配置文件的继承方面的差异，我没有在仓库中找到明确的答案。但是，从2.1.0版本到最新的2.2.0版本，对非properties格式配置文件的处理做出了一些改变，例如为非properties namespaces支持灰度特性。

对于你提到的问题，如果非properties格式的公共配置文件，继承依然是在整个文件内容粒度进行，我同意应该明确告知用户，并将相关case也表示出来。这将有助于用户更好地理解和使用Apollo。

Sources

• yml格式配置关联公共配置后，配置任意内容将会覆盖公共的所有配置
• 继承yml格式的 后覆盖属性, 再删除覆盖属性,会报错!
• docs/en/design/apollo-core-concept-namespace.md
• changes/changes-2.2.0.md

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[SSJSIAT]

@nobodyiam

[nobodyiam]

如果非 properties 格式的公共配置文件，继承依然是在整个文件内容粒度进行，请明确告知用户，并将相关case也表示出来

目前确实是这样的逻辑，对于用户的提示是否有啥建议？

[SSJSIAT]

当前提示不友好的点有2个：
1.官方说明文档（namespace部分）：没有明确写明非 properties 格式的公共配置文件，继承依然是在整个文件内容粒度进行
2.产品界面上（namespace Tips部分）：在关联的NameSpace里配置需要覆盖的配置即可，这其实只在properties 格式的公共配置文件可以这样操作
优化建议：
1.官方说明文档（namespace部分）：可以说明一下，（XX版本前），非properties 格式继承依然是在整个文件内容粒度进行，对于properties 格式，通过XX方式进行继承，对于非properties 格式，通过XX方式进行继承
2.产品界面上（namespace Tips部分）：可以参照上述表达，把不同的地方指出来
当前就我个人体会，是发现了问题后再回头找官方文档，最后只有从issue中才找到相关说明
或者说有这么一种使用场景：运维A习惯使用properties，他一直都这么使用，并形成了惯性思维，突然有一天有个应用要使用非 properties，这时候就可能没有注意到这点，问题就会发生

[nobodyiam]

很好的建议，如果有兴趣的话，欢迎直接提交 PR~

[IvanZheng]

请问什么时候能支持非properties的继承合并功能， 目前如果公共配置是json格式，内容为 { “k1": "a”, "k2":"b"} , 如果在覆盖配置中定义了{"k1":"c“}， 那么其实整个公共配置就都丢失了，只得到了{"k1":"c“}的结果（k2丢失了）， 这种情况下一旦使用了覆盖配置， 继承就失去意义了。