3
通过提供属性向用户公开集群成员的其他 URI 设置。 Neo4j-OGM 中的 API 存在很长时间，但从未通过自动配置进行访问。
Q
[spring-projects/spring-boot]添加对 Neo4j 附加因果集群 URI 的属性支持。
A
回答
3
感谢您的请求。
虽然我意识到 OGMBuilder类同时具有uri和uris方法，并且这里的提案反映了这一点，但我发现它令人困惑，我认为我们的用户也会如此。除了必须使用两个单独的属性来配置将使用的 URI 之外，看起来设置属性uris还需要将属性的值uri更改为bolt+routingURI。
我认为一种更像 Boot 的方法是支持单个属性来配置一个或多个 URI。然后可以将该属性配置为单个逗号分隔值、多个[n]索引属性或 YAML 中的列表。我们可以退后一步研究这样的方法吗？
7
感谢您研究此课程和相关Builder课程。我理解将两个参数合并为一个的想法是最好的方法，但它并不能反映 Neo4j-OGM 中配置的当前行为。这就是说，我更加感谢您提出这一点，因为我认为 Neo4j-OGM 中的配置也可能仅通过一个属性就变得更容易理解。
6
让我们暂时搁置这一问题，直到我们知道 Neo4j-OGM 中的 API 发生了什么。
0
@meistermeier 你有什么最新消息要告诉我们吗？
4
@snicoll 我刚刚更新了 PR，进行了更新、重新调整和压缩的强制推送。不允许（在 OGM 中）仅提供uris.由于向后兼容性，旧的仍然有效，但如果提供url则不再是强制性的。uris
9
@meistermeier 感谢您的反馈。我对“不允许……只提供 uri”和“旧网址仍然有效但不再强制”感到困惑
看看该提案，我想弃用uri并将所有人转移到uris.如果使用参数指定了一个 uri，uris那么它应该执行之前所做的操作，并且用户可以添加多个 uri 来访问我们在此讨论的功能。除了 Spring Boot 只会uris继续配置之外，它不会对您进行任何更改。
那有意义吗？
3
“不允许......”应该是“现在允许......”，抱歉造成混乱。弃用url对我来说很好，因为这也是将来 OGM 中也会发生的事情。那么让我们先把未来带入 Spring Boot 吧？
2
我们（再次）在内部讨论了这个问题，并得出结论，最好不要弃用该uri字段。更重要的是，该uris字段应该立即被弃用，因为我们希望用户将来使用单个入口点进入集群。当前 Neo4j 驱动程序的使用迫使我们让uris用户可以访问该属性，以提供多个可能的主机。在即将推出的驱动程序版本中，这将不再是必需的，但用户只需提供一个 uri。问题是，在我们拥有带有支持它的驱动程序的 Spring Data Neo4j 版本之前，我们必须公开该uris属性，以便用户可以设置其集群配置。
说到未来，我们将创建一个更接近驱动程序的配置，这样像现在这样的SDN、Neo4j-OGM和Java驱动程序之间属性状态不匹配的情况将不会再出现。
9
如果uris应该立即弃用，那么我不确定我们是否应该首先添加它，特别是如果没有可以使用的替代品，以便用户可以修复弃用警告。如果这样的替换已经存在，那么用户就可以使用它，如果不存在这样的替换，那么我们要么需要取消弃用该属性，要么根本不应该添加它。
2
我没有添加任何更改/弃用，因为我认为我们不应该“在发布时”弃用它。目前的情况以及大约未来 9 个月（至少）不会为用户提供除uris.Configuration目前，除了手动创建 bean 来通过 Spring Boot 属性实现此目的之外，没有其他解决方法。我的评论更多的是向您解释为什么我们不能通过uri此更改来弃用该属性。
8
谢谢，@meistermeier。听起来我们又回到了我上面评论的情况：
不幸的是，除非我误解了当前的情况，否则我认为我们应该拒绝这个提议并等待 Neo4j 中的事情得到澄清。同时，用户可以配置自己的Configurationbean。
2
至少现在我已经关闭了这个。如果我误解了，请告诉我们，我们可以重新考虑。
4
在重新思考整个 PR 之后，我认为 Spring Boot 从 PR 中退一步是最好的。不幸的是，删除或至少弃用的决定是uris在 PR 已经开放时发生的。另一方面，我们可以改进 Neo4j-OGM 作为副作用。感谢您的时间和想法。