小编Inv*_*con的帖子

我的一位同事在工作中介绍了静态工厂方法(在Effective Java之外),然后给出了一个用于获取静态/单例异常的示例.

这给我带来了一面红旗.有例外是否有状态？它们不是由JVM填充堆栈跟踪信息吗？你真正得到了什么节省,因为异常应该仅在特殊情况下发生？

我对异常的了解相当有限,所以我带着这个来找你:单例异常是否有效,有没有理由使用它们？

假设有2个标签P和M. M具有名称为M1,M2,M3..M10的节点.我需要将P的50个节点与M的每个节点相关联.标签P的节点也不应该与M的节点有2个关联.

这是我可以提出的密码查询,但似乎不起作用.

MATCH (u:P), (r:M{Name:'M1'}),(s:M) 
where not (s)-[:OWNS]->(u) 
with u limit 50 
CREATE (r)-[:OWNS]->(u);

这样我就可以运行M的所有10个节点.任何帮助纠正查询都是值得赞赏的.

我正在尝试编写一些注释来帮助将测试用例方法与各种元数据关联起来。到目前为止，我的注释包括 BugFix、UseCase 和 Requirement。我的最终目标是编写一个注释处理器来显示哪些测试用例与各个错误修复、用例和需求相关。

当我刚刚为自己的项目实现此功能时，我为每个测试关联类别创建了特定于我的项目的枚举。例如，我有 ProjectUseCase 枚举，我可以将其作为值传递给测试方法上的 UseCase 注释。这使得在一个地方添加额外的用例或修改用例变得很容易。

现在，我想让我工作中的其他开发人员可以使用此代码。当然，他们将致力于其他具有不同用例、要求和错误修复的项目。

以下是我遇到的问题：

1. 枚举无法扩展，因此我无法拥有其他人可以为自己的项目扩展的基本用例枚举。
2. 注释属性的值必须是常量。这阻止我在枚举上使用接口标记 (TestAssociation)，并使用 TestAssociation 接口作为注释的值。另外，这会阻止我在注释中使用 String 值，并在使用注释时传入枚举名称，例如：@UseCase(ProjectUseCase.GENERAL.name())。

据我所知，这让我只能使用原始字符串作为值，这剥夺了我的类型安全性和快速重构的能力。使用常量字符串类代替枚举似乎是处理此问题的最佳方法，因为每个开发人员都可以使用自己的类。

我唯一能想到的另一件事是引用 Enum 类（或常量字符串类），并且不将该类包含在 jar 中，将其留给用户实现。

有什么建议或解决方法吗？

我还想知道是否有任何项目已经提供类似的功能。

我有一个可以生成SecretKeys的应用程序，每个客户端一个。这些需要保留在我们的数据库中。我真的不熟悉常见的安全模式或实现，因此正在寻求建议。

KeyStore类似乎已被广泛使用，尤其是用于保护SecretKeys。但是，我几乎没有提及将KeyStore与数据库一起使用，并且我试图弄清这是因为它是基本用法（因此未提及），还是因为这是一种不良或多余的方法，我应该使用另一种技术。

基本设计是每个用户都有自己的密钥库，可以通过转换为字节（我想使用load（）和store（））将其保存到数据库中或从数据库中加载。

到目前为止，这种设计有什么问题吗？我也想知道应该如何处理KeyStore的密码。我们正在考虑仅对所有密钥库使用一个密码，但是如何在没有密钥库的情况下安全地存储此密码呢？

这是打算在后端应用程序中使用的，客户端将永远不会将密码传送给我们，服务器端也不会有人工操作员来提供密码。

我需要在现有节点之间创建关系，并尝试按照 youtube 创建动态节点和关系：https://www.youtube.com/watch? v=KsAb8QHClNg 几次，但我不认为它们涵盖了我的使用案件。

示例数据：

SOURCE  TARGET  LABEL   TYPE    SOURCE_TYPE TARGET_TYPE SOURCE_KEY  TARGET_KEY  PHLEVEL COLOR   SIZE    SCOPE
16      1   ERKRS_ROOT  DIRECTED    ERKRS   ROOT    ERKRS_R300  ROOT_EC3_800    0       #808080 1   FALSE
12      1   ERKRS_ROOT  DIRECTED    ERKRS   ROOT    ERKRS_INT1  ROOT_EC3_800    0       #808080 1   FALSE
51      1   KKBER_ROOT  DIRECTED    KKBER   ROOT    KKBER_GVK1  ROOT_EC3_800    0       #808080 1   FALSE
31      1   KKBER_ROOT  DIRECTED    KKBER   ROOT    KKBER_6000  ROOT_EC3_800    0       #808080 1   FALSE
71      1   FIKRS_ROOT  DIRECTED    FIKRS   ROOT    FIKRS_1000  ROOT_EC3_800    0       #808080 1   FALSE
334 …

我们公司有几个产品和几个团队.一个团队负责搜索,并将Elasticsearch标准化为nosql数据库以存储他们的所有数据,并计划稍后使用Neo4j来赞美他们的搜索关系数据.

我的团队负责社交应用程序的产品方面(人们有朋友,为公司工作,并且将与在公司工作的每个人一起成为同事).我们将图dbs视为一种解决方案(在放弃rdbms中n ^ 2关系的燃烧船之后),特别是neo4j(Cypher查询语言是一件很棒的事情).

我们的数据子集与搜索团队使用的数据类似,我们需要确保搜索可以同时搜索他们的数据和数据.搜索团队正在推动我们为我们的db而不是Neo4j或任何图形数据库标准化ElasticSearch.我相信这是为了标准化和一致性.

我们显然来自非常不同的地方,搜索问题与产品问题.他断言ElasticSearch可以涵盖我们的所有用例,包括类似图形的查询以查找建议.虽然这可能是真的,但我真的希望坚持使用Neo4j,并使用ElasticSearch插件与他们的搜索集成.

在这种情况下,对于产品数据库而言,选择ElasticSearch而非Neo4j是否存在任何重大问题(反之亦然)？那些处于类似情况的人的指导方针或轶事？