News for hackers. Stuff that matters.
Re:In-memory hash tree implementation by _ak on Sunday March 27, 2016 @09:58AM (#11369953)
Assuming that the underlying implementations of the Item interface will use some form of hash algorithm to determine the return value of the Key method, how does this deal with hash collisions of two distinct items?
Re:In-memory hash tree implementation by judofyr on Sunday March 27, 2016 @10:23AM (#11370028)
It doesn't. It's not a hash, it's the actual key.
Re:In-memory hash tree implementation by hit9 on Sunday March 27, 2016 @11:02AM (#11370148)
Yep.
Re:In-memory hash tree implementation by hit9 on Sunday March 27, 2016 @10:39AM (#11370073)
For this case, conflicts can be solved via the traditional separate chaining strategy, to open a list on the Item.

This htree was originally implemented as the indexing container to store key-value poisition informations for the bitcask storage engine. And string keys are not stored in the htree to save more memory. Collisions of two string keys are distinguished by checking the disk.

Re:In-memory hash tree implementation by hit9 on Sunday March 27, 2016 @11:11AM (#11370188)
And the origin string keys are stored in the htree item only if there is collision. So the string key distinguishing checks are at most once.
Re:In-memory hash tree implementation by songgao on Sunday March 27, 2016 @12:44PM (#11370527)
The Item interface requires a uint32 typed key, meaning that if you need a hash function to derive the key, you are responsible for resolving the collisions :D