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
