FEATURE: Add CompletableFuture BTree update API

[f1v3-dev]

🔗 Related Issue

• https://github.com/jam2in/arcus-works/issues/832#event-23130177064

⌨️ What I did

• B+Tree bopUpdate API를 v2(CompletableFuture 기반)로 구현했습니다.
• 연산을 위해 필요한 BTreeUpdateElement VO 클래스를 추가했습니다.
  • 업데이트 케이스에 따라 정적 팩토리 메서드로 생성합니다.
    • withValue(bkey, value) — value만 변경
    • withEFlagUpdate(bkey, eFlagUpdate) — EFlag만 변경
    • withValueAndEFlag(bkey, value, eFlagUpdate) — value + EFlag 함께 변경
  • 기존 v1 API에서 null을 직접 전달하는 방식은 호출자가 어떤 조합이 유효한지
    알기 어려웠으나, 팩토리 메서드로 유효한 케이스를 명시적으로 분리했습니다.

반환값 의미

• true — 업데이트 성공
• false — element가 존재하지 않음
• null — key가 존재하지 않음

[jhpark816]

리뷰 완료

[jhpark816]

질문입니다.
getEFlagUpdate() 용어와 일관되게 getBkey() => getBKey() 이어야 되지 않는 지?
보니, 기존 구현에서 모두 getBkey() 용어를 사용하는 것 같습니다.

[jhpark816]

getBkey() 용어에 관한 문제이니,
향후 리팩토링 시에 검토해 주시고, 본 PR에서는 skip 합니다.

[f1v3-dev]

현재 v2의 vo 패키지 내에서도 getBkey() 와 getBKey()가 같이 사용되고 있습니다.
전체적으로 bKey 라는 변수명과 getBKey() 라는 메서드로 통일이 필요하다고 보여집니다.

[jhpark816]

용어 통일은 별도 PR로 진행해 주시죠.

[jhpark816]

collectionUpdate와 CachedData를 따로 넘기는 것 보다
CachedData 생성하여 다시 collectionUpdate에 set하고
collectionUpdate만 넘기는 것이 좋지 않나 생각됩니다.
향후 리팩토링 대상이 되는 지 검토 바랍니다.

본 PR에서는 일단 문제 없습니다.

[f1v3-dev]

아래와 같이 변경할 수 있을 것 같습니다.

as-is

AsyncArcusCommands.java

// collectionUpdate
    CachedData co = null;
    if (collectionUpdate.getNewValue() != null) {
      co = tcForCollection.encode(collectionUpdate.getNewValue());
      collectionUpdate.setFlags(co.getFlags()); // flag 설정만 해주는 상황
    }

    // collectionUpdate + co.getData() 를 같이 넘기는 형태
    Operation op = client.getOpFact()
            .collectionUpdate(key, internalKey, collectionUpdate,
                    (co == null) ? null : co.getData(), cb); 

AsciiOperationFactory.java

  public CollectionUpdateOperation collectionUpdate(String key,
                                                    String subkey,
                                                    CollectionUpdate<?> collectionUpdate,
                                                    byte[] data,
                                                    OperationCallback cb) {
    return new CollectionUpdateOperationImpl(key, subkey, collectionUpdate,
            data, cb);
  }

to-be

AsyncArcusCommands.java

// collectionUpdate
    CachedData co = null;
    if (collectionUpdate.getNewValue() != null) {
      co = tcForCollection.encode(collectionUpdate.getNewValue());
      collectionUpdate.setFlags(co.getFlags());
      collectionUpdate.setData(co.getData()); // 변경될 데이터도 함께 저장 (별도의 data 필드 추가 필요)
    }


    // Operation 생성 시 collectionUpdate 만을 넘김
    Operation op = client.getOpFact()
            .collectionUpdate(key, internalKey, collectionUpdate, cb);

AsciiOperationFactory.java

  public CollectionUpdateOperation collectionUpdate(String key,
                                                    String subkey,
                                                    CollectionUpdate<?> collectionUpdate,
                                                    OperationCallback cb) {  // ← data 파라미터 제거
    return new CollectionUpdateOperationImpl(key, subkey, collectionUpdate,
            collectionUpdate.getData(), cb);  // ← collectionUpdate에서 꺼냄
  }

[f1v3-dev]

말씀해주신 방식대로 변경할 경우 CollectionInsert 또한 동일하게 작업이 가능할 것 같습니다.

[f1v3-dev]

민경님과 의견을 논의해본 결과 위에서 언급했던 collectionUpdate 리팩토링을 진행하는 방향으로 의견이 모아졌습니다.

다만, 현재 v2 작업 마무리가 우선순위가 더 높다고 보여지고 해당 리팩토링 작업을 진행하게 될 경우 v2 뿐 만 아니라 기존 API 내부 구현에 걸친 변경이 필요하므로, v2 작업 완료 후 전반적인 검토 과정을 진행할 때 리팩토링 작업을 하는 방향으로 진행하도록 하겠습니다.