This subject is of particular interest to my company as well. I have been in direct contact with @dan.flavin, Sr Systems Engineer at Neo4j, and he directed me towards this strategy:
Bob, I heard back about modifying each of the queries from the dev team. There’s been a service provider interface added to the Neo4j OGM to modify the Cypher statements generated by the OGM. The relevant postings are:
Blog: [https://medium.com/neo4j/neo4j-ogms-service-provider-interface-7e5bccbb72c4]
Github: [https://github.com/meistermeier/neo4j-ogm-label-extension]
The use of CypherModificationProvider does look promising, but implementing this strategy in a comprehensive way appears daunting. My attempted implementation of the neo4j-ogm-label-extension project hit a roadblock immediately in that it does not support the MERGE statement (in fact, it removes the label rather than adds it, appropriate in some cases but not others). See the Limitations section of the github page for more info, but suffice it to say that the project is incomplete at best. I am willing to contribute to this or a fork of the project, and would certainly welcome assistance from the community to make this thing more durable. Understand that this will require a good working knowledge of the openCypher spec and the AST it provides for statement parsing.
Another challenge here is devising a solution that works for every data access mechanism. I'm only a couple of months into Neo4j development and already have multiple access strategies, namely in java with neo4j-ogm and spring-data-neo4j, and liquigraph for changeset management. I am building Cypher strings directly in code, and using @NodeEntity objects, and also the Spring find methods. And (of course) direct Cypher via the Neo browser. Whatever solution we devise will have to support all those approaches in a bulletproof way. And at the very least, it will require a clear understanding of the limitations of each in supporting label modification.
So...perhaps connecting all parent nodes to a :Tenant node as suggested at the top of this thread is the safest approach? But that requirement seems prone to more complex and less performant queries.
I'd welcome any feedback, or working directly with anyone who is actively tackling this important challenge. The enterprise solution we're developing is dependent on this feature.
