Remodelling Prefix nodes

[romain-fontugne]

Problem

Currently it is incredibly hard to find the relationship between a BGPPrefix and its covering RIRPrefix if they are not the same prefix. Because we don't have a PART_OF relationship between these nodes.

However, simply adding this PART_OF relationship would not solve the problem. Because each node can have multiple types and if we embed the type of the source/destination nodes in the prefix_types property we would remodel the graph structure in the property and queries would become overly complicated.

Solution

The cleanest solution we can think of is to:

1. Separate the different types of prefixes into different nodes. E.g., we have one node for the BGPPrefix 1.1.1.0/24 and another node for the RIRPrefix 1.1.1.0/24.
2. Create PART_OF relationships between all the different types of prefixes, here we allow prefixes to be of the same size. E.g., the BGPPrefix 1.1.1.0/24 is PART_OF the RIRPrefix 1.1.1.0/24 and vice versa.
3. Create PART_OF relationships between nodes of the same type, but this time only to covering prefixes.

This will create some backward compatibilities (see below) but the benefits (possibility to relate different types of prefixes, cleaner modelling, and simplified queries) overweight the inconveniences.

Backward compatibility issues

• The prefix_types relationship is not needed anymore. So it will be removed. This is a good thing queries will be easier to write.
• If we keep the generic type, Prefix, then a lot of the current queries would still work. For example, (:AS)-[:ORIGINATE]-(:Prefix) is still valid even though it is not the preferred way to write this pattern. This would also ease the post-processing step where we find out all the prefix types that are in the graph.
  In this case, we will have multiple Prefix nodes with the same prefix attribute. This is currently not possible because of the constraint we add when we create the nodes. So we should create nodes using the specific type and then add the Prefix label (the opposite of what we are doing now).

[m-appel]

In this case, we will have multiple Prefix nodes with the same prefix attribute. This is currently not possible because of the constraint we add when we create the nodes. So we should create nodes using the specific type and then add the Prefix label (the opposite of what we are doing now).

That's actually a good point, I thought this would create more problems, but if we just reverse the order of operations it should work (it should also bypass the automatic creation of the unique contraint).

[romain-fontugne]

I think we are good to go. I'll modify the code and make a PR when I get it working.