Добавление вершины графа непосредственно в CosmosDB в формате GraphSON с использованием gremlinpython
Я использую gremlinpython для подключения к графу CosmosDB и хотел бы иметь возможность напрямую добавлять вершину с помощью словаря в формате GraphSON. В частности, я бы хотел избежать динамического создания запроса gremlin, например:
"g.addV('person').property(...)..."
и вместо этого запустите что-то вроде:
my_dict = {'id':'something', 'label':'person', 'outE':{}, 'properties':{}}
_gremlin_insert_vertex = "g.addV('person').use_my_graphson_dict({})".format(my_dict)
callback = client.submitAsync(_gremlin_insert_vertex)
Или что-то в этом роде. На портале Azure есть JSON-представление вершин из выполняемого мной запроса (например, "g.V()"), но я хотел бы получить его в Python с помощью gremlinpython, сделать обновления, а затем отправить JSON dict обратно для обновления или добавления вершины. Кажется, я не могу найти никакой документации о том, как конвертировать между объектами или запросами GraphSON dict и gremlin.
Ответы 2
В Gremlin такого API просто нет. У него нет шага, который мог бы принимать GraphSON или Dictionary (Map в Java), чтобы изначально преобразовать его в шаги property(). На протяжении многих лет в сообществе TinkerPop велась активная дискуссия по этой теме, поскольку удобство для пользователя такого шага, возможно, высоко, особенно в контексте, который вы описываете. К сожалению, введение Map не очень хорошо вписывается в API, как это могло бы показаться изначально, поскольку оно не позволяет должным образом настраивать мульти-свойства, если сигнатура шага не принимает Map<Object,List<Object>> (то есть в Python, Dictionary, где ключ - String или T а значение - это List произвольных объектов), который сложнее построить и обдумать. Более того, этот API плохо учитывает мета-свойства, если рассматривать их в общем контексте того, как они установлены. Есть и другие аргументы против этого, но они всегда остаются в моей памяти.
Что касается шага, принимающего сам GraphSON (который, я полагаю, смягчил бы некоторые из проблем, о которых я упоминал выше, с multi / meta-свойствами), я не думаю, что это когда-либо предлагалось. Я не уверен, как это будет работать, поскольку GraphSON - это функция операций ввода-вывода, а сам язык Gremlin просто никогда не знал об этом. IO - это абстракция, далекая от Гремлина, и я не уверен, что она там хорошо вписалась бы. Я также думаю, что большинство пользователей жаловались на сложность GraphSON (словари со встроенными списками или списками и т. д.) И что создание GraphSON вручную нетривиально, и поэтому я сомневаюсь, что многие сочтут такой API привлекательным для них. Мульти / мета-свойства снова поражают! :)
Я бы также сказал, что TinkerPop категорически против создания строк из Gremlin. Вы вынуждены сделать это сейчас в CosmosDB, поскольку они еще не поддерживают API байт-кода. С этой поддержкой (над чем они работают) вы больше не будете отправлять Gremlin как значение String, а вместо этого будете писать Gremlin на своем любимом родном языке (в вашем случае Python). Таким образом, разработка путей, которые дополнительно побуждают пользователей «строить строки» любого вида, GraphSON или Gremlin, вероятно, не будет поощряться.
Теперь, в Python, вы можете создать этот метод самостоятельно как часть настраиваемого DSL Gremlin, который в основном принимает Dictionary и преобразует его в вызовы property(). Поскольку логика будет специфичной для вашего приложения, вы можете учесть любые проблемы с мета / несколькими свойствами, которые могут или не могут быть у вас. Вы можете узнать больше о том, как создавать DSL здесь и узнать больше о шаблонах для реализации в этой серии сообщений блога: Часть I, Часть II и Часть III..
Я думаю, что мы могли бы увидеть этот тип API, родной для Gremlin, в 4.x, когда будет расти поддержка отказа от поддержки мульти / мета-свойств, но до тех пор хороших идей не было.
Кроме того, я пытался концептуализировать модели данных на основе графов в Python и как лучше всего передавать данные на основе графов между различными компонентами моего кода. Я создал собственные классы Vertex и Edge, в которые я включил методы для сброса и загрузки их в / из формата GraphSON, потому что это то, что CosmosDB, похоже, указывает в своей документации (например, docs.microsoft.com/en-us/azure/cosmos-db/…)
Звучит так, как будто я должен вместо этого начать, чтобы эти объекты использовали Gremlin DSL напрямую для взаимодействия с CosmosDB, а не сначала преобразовывали в GraphSON (как только они поддерживают эту функцию)? Я собираюсь сейчас прочитать серию ваших блогов, но в целом это имеет смысл. Спасибо за помощь.
когда я упомянул подход DSL, я забыл, что вы используете cosmosdb. обратите внимание, что в этом сценарии вы не можете использовать собственный gremlin, потому что в настоящее время cosmosdb не поддерживает формат запроса байт-кода, который используют варианты языка gremlin. эта поддержка идет, насколько я знаю.
Это на год позже, так что к настоящему времени вы либо решили эту проблему, либо уже не заботитесь о потомках ...
Вы можете использовать клиент sql python для своей коллекции графов и использовать метод вставки документа для отправки 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"
}
Некоторое время назад я говорил об этом с помощью блоггинг - хотя я тестировал его только в .NET SDK.
Интересно. Я действительно нашел другой способ сделать это, в основном пытаясь более внимательно проследить за предполагаемым использованием Gremlin. Но мне нравится идея иметь это в качестве опции, и мне не приходило в голову, что SQL вообще будет возможен.
Очень интересно и познавательно. Моя первоначальная мысль, не имея возможности использовать сам dict GraphSON, заключалась в создании строк Gremlin, как вы указали, поскольку это, по-видимому, единственный вариант, обсуждаемый в различной документации и источниках CosmosDB. Однако быстро становится очевидным, почему TinkerPop это не нравится, и с точки зрения Python это кажется очень непитоническим.