When guaranteed uniqueness on index-level is supported this can probably be implemented. Have one indirection in an index adds overhead but I image it's only for one or more starting points and then it's internal ids all the way from there.
2011/11/9 Michael Hunger <michael.hun...@neotechnology.com> > I think a separate UUID (2xLONG = 16 Bytes) property type would make > sense, if I remember correctly property types with larger block sizes are > now possible. > Otherwise it could be an inlined long[2]. > > Having good support on the API level (integrated separate fast index + > uniqueness) would be important as well. > > That would come at the cost of dropping the exposure of native neo4j-ids. > I think that's a worthwhile trade-off. > > Michael > > Am 09.11.2011 um 17:02 schrieb Jim Webber: > > > Hey Peter, > > > > I think you raise a good point. We'll need some kind of ID for objects > stored in (v)shards, but that's likely to be some kind of hierarchical ID > (so that we can locally and globally refer to objects in and across shards). > > > > I think here the question boils down to: can we add (fast) support for > UUIDs natively in our store, like we do for strings. I don't know the > answer to that, but the kernel folks can probably offer some insight. > > > > Jim > > _______________________________________________ > > Neo4j mailing list > > User@lists.neo4j.org > > https://lists.neo4j.org/mailman/listinfo/user > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Mattias Persson, [matt...@neotechnology.com] Hacker, Neo Technology www.neotechnology.com _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
