RETURN propertyTypes(n) feature + fast retrieval of property types of an entity from property manager

[LucLabarriere]

• Loading times from the binary before/after: 2.9/3.2 seconds (reactome)
• quiet mode MATCH (n) RETURN propertyTypes(n) on reactome: 400 ms
• quiet mode MATCH (n)-[e]->(m) RETURN propertyTypes(e): 508 ms

[cyrusknopf]

Also any thoughts on how this would work w.r.t SET?

[LucLabarriere]

Also any thoughts on how this would work w.r.t SET?

That's a good question, I would say:

• The PropertyTypeSet is the representation of the properties a node has in the current DataPart, it's not related to deletes or updates
• If a node has a new property in a later datapart, it gets a dedicated PropertyTypeSet in the new datapart (say property type id 5):
  • Datapart 0: set = [0, 1, 2]
  • Datapart 1: set = [5]

For deletions, we will have to have some sort of tombstones on property types, our delete the node itself ?

[rjb32]

Why do we need to even deduplicate with an unordered_set here? Why can't we just give the property types of each NodeID regardless of repetitions?

[LucLabarriere]

This is mostly for the SET command and it depends how it will be implemented. If we just append modifications in newer dataparts, a node will have multiple definitions of the property and the property type ID will appear multiple times.

SET n.displayName = "hello"
COMMIT
SET n.displayName = "world"

displayName is defined twice (in two dataparts), hence the need to deduplicate. That will depend on the actual implementation of SET

[cyrusknopf]

Looks nice, I think it works well with the current SET implementation, currently you can't delete properties anyway, so whilst it might need a rethink to support that, so will the SET itself.

It is worth adding a unit test for testing the rebase behaviour. I have tested the below manually and it appears to work:

change new
change new

checkout change-1
match (n) where n.name = "Cyrus" set n.age = 23, n.new_prop1 = false
change submit

checkout change-0
match (n) where n.name = "Remy" set n.new_prop2 = true
change submit

match (n) return n.name, n.propertyTypes()

i.e. both changes create a new property, and they should be rebased correctly so that Remy has new_prop2 and I have new_prop1. We need this case and other similar examples in ChangeQueriesTest.