Michael Hunger wrote: > > Probably we have to add this unique property behavior to the auto-indexing > framework. > > Right now we have no means to mark properties as unique. > > So whenever you take a different node and set one of its "unique" > properties to a value already contained in an unique index it should fail > on commit, this is the point where the auto-indexing would come into play. > > There should probably also be a different index type (besides the "exact" > and "fulltext" types that handles unique values and for instance fails at > duplicate key insertion. > > We would have to provide the low-level methods for the obtain* operations > which you could use in the embedded graphdb mode. All other operations > should be protected either by auto-indexing storing the values in the > unique index. >
Hi Michael - Yeah, that's sounds right, Then you could use the unique index methods to do things like build a "create or update" endpoint or a "create or update batch" endpoint that would allow you to efficiently load a user's social graph. I added a ticket here... http://neo4jdb.lighthouseapp.com/projects/77609-neo4j-community/tickets/12-add-unique-property-behavior-to-the-auto-indexing-framework Thanks. - James -- View this message in context: http://neo4j-community-discussions.438527.n3.nabble.com/Are-Unique-Indices-in-the-Works-tp3229971p3232258.html Sent from the Neo4j Community Discussions mailing list archive at Nabble.com. _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
