Add values to Augmentation functions

[shuoli84]

This is a rough workable version to handle duplicate values with "Upsert" approach.

[shuoli84]

#24 ref

[YeungOnion]

Hmm, but key removal and reinsertion might require rebalancing twice (I did not prove this, but I believe it is true).

Perhaps I am simply wanting too specific of a behavior from a general data structure while maintaining all of its advantages.

[shuoli84]

Just tweaked the Augmentation trait, and pass in the values reference. The code indead looks much cleaner.
But "get_mut" functions won't update the augmentation. I think it is ok as long as we make it clear in the doc..

[shuoli84]

fn insert(tree: &mut BPlusTree<NodeStoreVec<i64, usize, Count>>, key: i64) {
    let prev_count = tree.get(&key).cloned().unwrap_or_default();
    tree.insert(key, prev_count + 1);
}

fn delete(tree: &mut BPlusTree<NodeStoreVec<i64, usize, Count>>, key: i64) {
    let prev_count = tree.get(&key).cloned().unwrap_or_default();
    if prev_count == 1 {
        tree.remove(&key);
    } else {
        tree.insert(key, prev_count - 1);
    }
}

[YeungOnion]

Hey thanks for doing this!

I suppose that implementing key only augmentations will be optimized by the compiler. Did you compare any benchmarks to make sure you're not losing out on perf?

[shuoli84]

Noop, I did not do any benchmark yet. I believe the compiler should kick in and optimize it, but that's hard to say... It would be great to define a new set of benchmark for augmentation features.

Before doing that, do you think the implementation suits your use case?

[YeungOnion]

It looks to me like the count_as_value example is what I need. I tried it in a few different cases, and it seems to work as expected.

So is your plan to document that values can be used, but that implementors of Augmentation should know that there will be logical errors if values are mutated in-place instead of with the insertion API?

[shuoli84]

Yup. I think the use case is common and the likelihood of both "get_mut and update" + "Augmentation based on Value" is low.

[YeungOnion]

I think so as well, and at least it would only be a logic error, similar to mutating key in-place in a collections::BTree*