> > I will try to do it ... if I found enough time ...
> Great! Let me know when you start something, so we don't waste efforts.
No problem, I will keep you informed.
> It means each key inserted in the B+Tree must be unique. If you want to
> bind multiple values to a key, you must either 1) wrap these values as a
> single value, like a HashMap for example, or 2) place aa recid as a
> value, which points to a persistent collection (such as a persistent
> linked-list -- which we don't really have now :(.
or wrap the key into unique super key composed of an integer and the
original key, with custom and simple serialization methods.
For ArrayList or LinkedList, why not to consider a B+Tree with key=Integer.
or some degerative form ...
BTW having a B+Tree wrapped in a persistent "TreeMap", you get also
implementation of a TreeSet.
> The design decision not to support duplicate values directly allows the
> implementer to pick the most appropriate locality of storage. You can
> have values in-lined in the BPage (very fast for small values) or
> reference a distinct collection with a recid (more efficient for large
> values). I didn't want to impose a constraint there.
> A collection wrapper for a B+Tree would typically choose which approach
> to take, depending on the nature of the stored data.
> Alex Boisvert boisvert@...
> Project Manager, Intalio Inc. http://www.intalio.com
> Operate at the Process Level <SM> (650) 345 2777
> Jdbm-general mailing list
> End of Jdbm-general Digest