解决#13746。
一些注意事项：
授权密钥访问已转变为在需要授权密钥的基于推送的注册表中内部每次发布时进行延迟评估。这样做的目的是允许用户在运行时轮换密钥。
此 PR 包含两个提交，其中第二个提交向 InfluxDB 的配置添加了 3 个新属性。虽然我通常会为次要版本保留这样的添加内容，但我认为这些属性之前是“遗漏错误”。我们收到的反馈表明，保留策略对于任何生产 Influx 数据库配置都是至关重要的。如果您决定在 2.0.4 中不允许这样做，请选择 master 分支，否则我可以打开一个单独的 PR。
谢谢，乔恩。我想现在已经太晚了，但是如果新的持续时间属性是Duration.它将确保在 Boot 的所有属性中对 aString到 a 的映射进行一致处理。Duration他们可能超载了吗？
（例如 2 小时、52 周）
@jkschneider 我明白你已经复制了 Spring Boot 的Duration格式吗？如果我们想公开Duration自己的立场，这一点很重要，因为我们需要提供一个String可行的方案。你能多解释一下这种格式是如何工作的吗？例如，我们可以传回毫秒数吗？
@snicoll查看代码，它的Influx 持续时间与Spring Boot 的不同。
谢谢约翰尼！
@wilkinsona，如果您愿意，InfluxProperties我们可以制作它们Duration，但是我们必须编写序列化逻辑以将它们重新填充到InfluxPropertiesConfigAdapter.最终，我们必须将字符串发送到 Influx。
谢谢，@jkschneider。我现在对此很纠结。String-> Duration->往返的好处String是，如果用户提供了格式错误的值，我们会提前失败。如果我们只是直接通过，String则在调用 Influx 之前不会发生故障。缺点是，如果用户熟悉 Influx，他们可能会本能地期望能够使用 Influx 的持续时间格式，并且正如 @izeye 上面指出的那样，它与 Boot 的略有不同。总的来说，我倾向于String直接通过。
String如果在合理的情况下，放松 Spring Boot 中的Duration转换规则以适应 Influx 持续时间怎么样？
这不是破坏了我们的和谐Duration吗？我知道这个很微妙，因为它复制了一种相似但不同的格式，但我想我希望我们保持一致。我希望我们也duration像在其他地方所做的那样删除属性名称的一部分。
这不是破坏了我们为持续时间所做的协调吗？
不，我不这么认为。
我相信，在我们使用的所有其他地方Duration，传递到我们正在配置的组件中的值是一个数字。使用Duration提供了围绕数字单位的灵活性。在这种情况下，传递到我们正在配置的组件中的值是String.
我希望我们像在其他地方所做的那样删除属性名称的持续时间部分。
这将为我们留下名为retention和 的属性retentionShard。我认为他们没有道理。DURATION和SHARD DURATION是命令中的子句CREATE DATABASE。与其他一些子句相结合，它们创建数据库的保留策略。我认为当前的属性名称准确而简洁地反映了它们的功能。
如何在 Spring Boot 中放宽字符串到持续时间的转换规则，以便能够在合理的情况下适应 Influx 持续时间？
不幸的是，我认为u or µ这是不合理的，因为它只是意味着没有单位的微型。它们有ns纳秒和ms毫秒，这使得u or µ更加令人困惑，因为它看起来像是任何事物的百万分之一。
对此平衡的另一个论点是工具支持（Duration正在或将被支持，而这个特定的字符串需要自己的解析器，这可能意味着根本不支持）。如果这是我推动这一目标的主要原因，我想也就不足为奇了。
也许我还期望 Spring Boot 用户能够更轻松地了解他们在 Spring Boot 中所了解的内容，而不是涌入的特殊性。如果我是对的，那么这应该会让人感觉很奇怪，因为一般来说，持续时间有一种得到良好支持和记录的格式，但这个特定属性的行为有所不同。
我认为这里的关键是这不是java.time.DurationInfluxDB持续时间。不幸的是，这个术语的含义过多，但它们是不同的事物，我现在认为我们应该这样对待它们。
鉴于我们无法控制 InfluxDB 持续时间的格式，并且不能保证它不会与 a 进一步偏离java.time.Duration，我得出的结论是，将其用作java.time.Duration属性的类型是错误的。这样做会让我们陷入困境，并且可能使用户无法指定在 InfluxDB 中完全合法的值，但我们不希望或无法在我们的转换器中支持该String值java.time.Duration。
感谢您的反馈。我同意这是正确的做法。