dstagner · January 27, 2014 15:54
diff --git a/multikey_constraints_neo4j b/multikey_constraints_neo4j
 Problem: In a data structure, sometimes we want constraints on more than one key. But right now, the Neo4J 2.0 uniqueness constraint really only supports uniqueness on one key. 

 Example: Parents (the meatspace kind) can have several children. None of their children should have the same name. However, their children may have the same name as children of other parents. So you don't want uniqueness on names for all children, but you want uniqueness on names for children of specific parents. This is two-key uniqueness. 

 Victor has three children - Mary, Alice, and Quasimodo. And Marissa has three children - Xena, Bob, and Alice. Victor's Alice and Marissa's Alice are two different children, but have the same name. 

 Solution: Create a unique key on parents (like a uuid, since parents shouldn't be unique on name). Then create a unique key on child that's a combination of parent uuid and child name. Kind of a hack, but it should work. 

 More later when I actually write an implementation.
	Problem: In a data structure, sometimes we want constraints on more than one key. But right now, the Neo4J 2.0 uniqueness constraint really only supports uniqueness on one key.

	Example: Parents (the meatspace kind) can have several children. None of their children should have the same name. However, their children may have the same name as children of other parents. So you don't want uniqueness on names for all children, but you want uniqueness on names for children of specific parents. This is two-key uniqueness.

	Victor has three children - Mary, Alice, and Quasimodo. And Marissa has three children - Xena, Bob, and Alice. Victor's Alice and Marissa's Alice are two different children, but have the same name.

	Solution: Create a unique key on parents (like a uuid, since parents shouldn't be unique on name). Then create a unique key on child that's a combination of parent uuid and child name. Kind of a hack, but it should work.

	More later when I actually write an implementation.