I would like to change BTree.size() and BTree._entries such that a long is used to track and report the #of entries in the BTree. This change can not be backward compatible in the store since the Externalizable format will be changed (to write a long vs an int for the #of entries). However the impact of the change could be limited by adding
public long size2();
which would return the long count and then modifying
public int size();
to return the int value iff the size can be represented within an int.
A couple of thoughts:
1. Use the current _entries value stored in the file either the actual value, or a marker (if it's value in the file is -1) that the real stored value is stored in the next 8 bytes. It will require an additional 4 bytes of file space if you are actually using a large value for entries, but will remain backwards compatibility (and not consume additional file space - like that matters) - for those that don't need it.
2. I'm OK with adding the size2() method if binary compatibility must be maintained, but it does clutter the interface. We should mark size() as deprecated, and plan to phase it out in 2.0.
3. The name size2() is a bit ... hackish... how about entryCount() or entries() or elementCount() ?
Anyone else have any comments?
Ok. I will approach it that way (-1 indicates read next 8 bytes for the read size) and use entryCount().
I will also review the other fields for exposure via the public API. I have a use case for getting back the comparator in use by the BTree, so I have that pain already.
While you are at it, can you please expose the key and value serializers ?
If you are trying to keep a link to the tree in the object stored in the tree, this is a big help.
Done. The key and value serializers are now exposed (read only).