使用gremlinpython以GraphSON格式将图顶点直接添加到CosmosDB

Question

我正在使用gremlinpython连接到一个CosmosDB图，并希望能够使用GraphSON格式的字典直接添加顶点。具体来说，我希望避免动态构建gremlin查询，例如：

"g.addV('person').property(...)..."

而是运行类似于：

^{pr2}$

或者类似的东西。Azure门户有一个来自我运行的查询的顶点的JSON表示（例如"g.V()"），但我希望能够使用gremlinpython将其导入Python，进行更新，然后将JSON dict发送回更新或添加顶点。我似乎找不到任何关于如何在graphsondict和gremlin对象或查询之间转换的文档。在

Answer 1

这已经晚了一年，所以现在你要么已经解决了，要么不再关心后代了。。。在

您可以对graph集合使用sql python客户机，并使用insert document方法发送一个json，该json对于一个顶点具有有效的Graphson结构：

像这样：

{
    "label": "person",
    "firstName": [{
        "_value": "Thomas",
        "id": "5267ec4b-a39e-4d77-8dea-668cb36307bc"
    }],
    "lastName": [{
        "_value": "Andersen",
        "id": "2e5271a6-ddd8-48b9-8ff6-be41e19f82f8"
    }],
    "age": [{
        "_value": 44,
        "id": "1c9a57cc-3324-4a0c-b4c3-d494fbb3fb81"
    }],
    "PartitionKey": "123",
    "id": "a9b57684-16bf-47d9-8761-570bab43ca7b"
}

我不久前就谈到过这个问题—不过，我只在.NETSDK中测试过它。在

Answer 2

Gremlin中根本没有这样的API。它没有一个可以接受GraphSON的步骤，也没有一个Dictionary（Java中为Map）来将其本机转换为property()步骤。多年来，TinkerPop社区对这个主题进行了大量的讨论，因为这样一个步骤的用户方便度可以说是很高的，尤其是在您描述的上下文中。不幸的是，引入Map并不能很好地融入到API中，因为它不能正确地允许设置多属性，除非步骤签名接受Map<Object,List<Object>>（即在Python中，一个Dictionary，其中键是String或T，值是任意对象的List），其构造和推理更加复杂。此外，如果将这些属性放在如何设置的一般上下文中，该API并不能很好地考虑这些属性。也有其他反对它的论据，但这些都是我脑海中最常出现的。在

至于接受GraphSON本身的步骤（我想这会减轻我在上面提到的multi/meta属性的一些问题），我认为从来没有人提出过这个建议。但我不确定这是如何工作的，因为GraphSON是IO操作的函数，而Gremlin语言本身根本就不知道这一点。IO是一个远离Gremlin的抽象概念，我不知道它是否适合那里。我还认为，大多数用户都抱怨GraphSON的复杂性（带有嵌入列表或列表的字典等等），并且手工构建GraphSON是非常重要的，因此我怀疑很多人会发现这样的API对他们有吸引力。多属性/元属性再次攻击！：）

我也要说，TinkerPop非常反对构造Gremlin字符串。你现在不得不在CosmosDB中这样做，因为他们还不支持字节码API。有了这种支持（他们正在研究的东西），您将不再将Gremlin作为String值提交，而是用您最喜欢的母语编写Gremlin（在您的例子中是Python）。因此，开发进一步鼓励用户“构造字符串”的路径，不管是GraphSON还是Gremlin，都可能会受到阻碍。在

现在，在Python中，您可以将此方法作为自定义Gremlin DSL的一部分构建，该DSL基本上接受Dictionary并将其转换为property()调用。由于逻辑是特定于您的应用程序的，您可以解释您可能存在或不存在的任何元/多属性问题。您可以阅读有关如何构建dsl的更多信息here，并在这个博客文章系列中了解更多关于实现的模式：Part I，Part II，和Part III。在

我认为当人们越来越倾向于放弃对multi/meta属性的支持时，我们可能会在4.x中看到这种源于Gremlin的API，但在此之前还没有太多好的想法。在