openforcefield
`py2neo` `Transaction.merge` doesn't allow for multiple relationships of the same type between the same two nodes, even with differing attributes
If a user wishes to include Transformations that feature the same ChemicalSystem as stateA and stateB, this currently results in an inconsistent state in the state store for the resulting AlchemicalNetwork represented there.
Although neo4j is technically capable of representing this situation as we desire, py2neo Transaction.merge does not create it properly. We use Transaction.merge to create the neo4j representation from the py2neo Subgraph representation, and from the py2neo docs, this behaves as:
For each relationship, the merge is carried out by comparing that relationship with a potential remote equivalent on the basis of matching start and end nodes plus relationship type. If no remote match is found, a new relationship is created; if a match is found, the properties of the remote relationship are updated.
This means that use of Transaction.merge cannot ever result in two relationships of the same type sharing the same start and end nodes, even if those relationships feature attribute differences.
This may not be easily addressed so long as we are relying on py2neo, and may only be practically solvable when we move away form it. See #144 for more details.
As a mitigation, we could for now add detection of the common source of this issue (Transformation of the same ChemicalSystem as stateA and stateB) in the state store codepath and raise an exception that can be reported back to the user. That would give users immediate feedback on the problem, and point out to them that something is probably wrong with their AlchemicalNetwork.
We could also perform this check in the AlchemiscaleClient.create_network call, since this will be much faster. Putting in both places is helpful as guardrails to protect consistency of the DB.