Графики и контроль версий

Question

У меня есть структура данных ориентированного графа, где я пытаюсь реализовать индивидуальный контроль версий для каждой вершины.Это создает некоторые интересные сценарии, и я был бы очень признателен за любые идеи, которые вы, ребята, имеете.В частности, я пытаюсь разрешить поведение системы по умолчанию при обнаружении указанных сценариев.

См. Следующее изображение: Версии графика

Сценарий 1:«Парадокс нулевого указателя»

Вершина A откатывается до версии 1.0.Поскольку этот откат будет каскадно перемещаться вниз по подграфу, C больше не будет указывать на D. Это может создать опасность.Если поведение будет следующим:

• 1.1: удалить ребро C -> D, создать разбитый график
• 1.2: удалить D, оставив E сиротой
• 1.3: Удалить D и E
• 1.4: Отказаться от отката до того, как будут удалены все ребра, указывающие на D (в данном случае это будет E -> D)
• 1.X: Альтернативные решения?

Сценарий 2: «Косвенные эффекты»

Обновлена ​​вершина D, так что выполняется следующее:

• Dтеперь версия 1.2
• E теперь версия 1.1
• C теперь версия 1.3
• A теперь версия 1.3

Вершина A сейчасоткатился до версии 1.2, так что выполняется следующее:

• A теперь версия 1.2
• C теперь версия 1.2
• D теперь версия 1.1

Если поведение по умолчанию должно быть:

• 2.1: Откат E до 1,0
• 2.2: Отказ от отката из-за опасности версии, что ухудшаетфункциональность
• 2.X: Альтернативные решения?

Answer 1

То, с чем вы сталкиваетесь, является очень сложной проблемой, и хотя я не знаю о целенаправленных исследовательских проектах, особенно в этой области, я слышал о некоторых попытках решить эту проблему.в принципе невозможно вытащить быстрое и грязное решение.Я могу указать вам на предыдущие вопросы, которые я задавал по этому поводу (графики и управление версиями):

• триплет с ревизиями
• Графические базы данных и RDFtriplestores: хранение графических данных в python

В итоге я отказался выполнять какой-либо контроль версий, но вместо этого каждый раз создавал новые узлы с новыми удостоверениями.Я теряю откат, я теряю любой вид отслеживания, но я сохранил управляемость.

На практике единственное, что вы можете сделать, - это иметь контроль ревизии для графика в целом.Это очень трудно иметь для отдельных узлов.Все проблемы, которые вы описываете, проистекают из того факта, что вы проходите сквозные слои транзакций, где на каждом слое у вас есть непротиворечивый график, сформированный в определенный момент времени.Если вы пересекаете эти слои, позволяя контролировать ревизию вершин, вы имеете дело с банкой червей размером с дюну.

Answer 2

Мне кажется, что здесь есть некоторая путаница с гранулярностью.Если вы версировали только отдельные вершины, но не граф, то откат отдельной вершины не должен влиять на остальную часть графа.Если, OTOH, вы хотите откатить весь граф, тогда вам также следует создать версию всего графа.

Проблема в том, что если вы версируете только отдельные вершины, то у вас есть толькогарантии целостности для отдельных вершин, но не для графа в целом.Таким образом, если, как вы описываете это, откат отдельной вершины «рябит» весь граф (или, по крайней мере, связанный подграф), то вы не гарантированно окажетесь в согласованном состоянии.

исследование, которое кажется наиболее близким к тому, что вы пытаетесь, касается контроля версий для XML, который, однако, имеет дело только со строго типизированными деревьями (вырожденными графами IOW), а не с общими графами.

Answer 3

Antiquity - версионная реализация графа для Blueprints (таким образом, она работает и с neo4j), Взгляните на: https://github.com/asaf/antiquity