I would go with a simple Iterator. Regards, Pierre-Arnaud
On 16 sept. 2013, at 11:51, Emmanuel Lécharny <[email protected]> wrote: > Le 9/16/13 11:41 AM, Kiran Ayyagari a écrit : >> On Mon, Sep 16, 2013 at 3:00 PM, Emmanuel Lécharny >> <[email protected]>wrote: >> >>> Le 9/14/13 9:45 AM, Kiran Ayyagari a écrit : >>>> On Sat, Sep 14, 2013 at 1:00 PM, Emmanuel Lécharny <[email protected] >>>> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> >>>>> /** >>>>> * @return The array of stored values. >>>>> */ >>>>> V[] getValues(); >>>>> >>>>> shouldn't this be returning a BTree<V,V>? cause we don't support an >>> array >>>> as a holder of >>>> multiple values >>> The fact that it's stored as a BTree is implementation dependent, I'm >>> not sure the user of the API should know about it. What the user wants >>> is to get back the stored values, and this is convenient to get back an >>> array. >>> >>> IMO, it is not convenient, we cannot copy all the values into an array >> and return, and returning an iterator is not going to help either, both will >> severely affect the search performance >> If needed, we can wrap it an immutable structure and return the BTree >> to prevent direct updates, but I wish to differ this until we see the impact >> on partition implementation. > > Except that from the BTree interface, the one the users see, you have : > > public V get( K key ) throws IOException, KeyNotFoundException > public DuplicateKeyVal<V> getValues( K key ) throws IOException, > KeyNotFoundException > > so the users has no clue about the underlying data structure. > > Now, I'm not sure if it makes any sense to expose a getValues() method > returning an array. May be an iterator is enough.. > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
