Sup2

@jhpark816 @hjyun328 저도 형준 선임 의견 제안에 동의합니다. 현재는 all or nothing 형태로 캐시 조회가 이루어지고 이를 개선한 API가 getSome()으로 Exception 발생 전까지 일부 성공한 key에 대해 조회할 수 있습니다....

@jhpark816 @hjyun328 저도 동의 합니다. 사용자 관점에서 모든 인자가 반드시 입력이 필요한 필수인자로 느껴져 혼란을 줄 수 있다고 생각합니다. 생략 가능한 인자에 관해서는 생략한 API를 제공하는게 사용자에게 좋을것 같습니다.

@jhpark816 @hjyun328 생략가능한 인자를 가진 API는 아래와 같습니다. 생략가능 인자를 제외하고 필수 인자만으로 이루어진 API를 추가하면 될 것 같습니다. ```java // b+tree CollectionFuture asyncBopGet(String key, long bkey, ElementFlagFilter eFlagFilter, boolean...

@oliviarla server의 ascii 문서를 참고하여 1. 생략가능한 인자를 제외한 API (필수 인자) 2. 그외에 생략가능한 인자를 부분적으로 포함한 API 도 고려 추가할 API 목록을 작성 후 작업을 진행하면 됩니다.

@oliviarla bopGet 의 offset arugemnt는 생략 불가능 한가요? 그외 다른 API의 offset 도 마찬가지로 생략 불가능 한가요?

@jhpark816 @oliviarla 제네릭 type T를 사용한건 class의 type을 제한하기 위해서 입니다. ``` CollectionFuture asyncBopInsert(String key, long bkey, T value, CollectionAttributes attributesForCreate, Transcoder tc) ``` 위의 API 와 같이 Transcoder에 제네릭T가...

@oliviarla ``` CollectionFuture asyncBopDelete(String key, long from, long to, int count) //count(필수): from~to 범위 내에서 앞에서부터 count 개수만큼 삭제 ``` 작성해준 API중에 위의 API도 count 를 제거해도 될 것 같습니다.

@jhpark816 @oliviarla overloading의 목적으로 동일 API들이 `CollectionFuture` type으로 반환하고 있으며, 그외 asyncBop, asyncMop, asyncLop 도 동일하게 `CollectionFuture` type으로 반환하므로 일관성에서도 문제 없습니다.