Hi, > I suggest that we define a set of relevant > performance benchmarks, and use them for > evaluating potential alternatives.
Sounds good to me. This thread isn't about UUIDs, I'm sorry if this was not clear. By the way, a UUID doesn't have to be randomly distributed. For example Microsoft introduced sequential UUIDs in SQL Server 2005 - http://msdn.microsoft.com/en-us/library/ms189786.aspx - Other libraries / products support this as well. We could also use such sequential UUIDs in Jackrabbit (2 or 3) for the jcr:uuid property. Regards, Thomas On 3/6/12 5:01 PM, "Jukka Zitting" <[email protected]> wrote: >Hi, > >This thread is confusing two different things: the UUID accessible as >the jcr:uuid property of a JCR node, and the internal reference used >by the underlying storage implementation to locate a specific node >state. In Jackrabbit 2.x these are the same, but in jr3/oak this is no >longer the case since the MVCC model implies that the internal storage >references change at each content change. > >IIUC Thomas' original post was about the latter case, i.e. the >internal storage references, *not* jcr:uuid properties. > >The tree interface we've been drafting in the other thread explicitly >hides the underlying storage identifiers, which should help isolate >this design decision from higher levels of code. > >Rather than discuss this issue in the abstract, I suggest that we >define a set of relevant performance benchmarks, and use them for >evaluating potential alternatives. > >BR, > >Jukka Zitting
