FEATURE: Replace BopGetArgs with operation-specific args classes

[f1v3-dev]

🔗 Related Issue

• https://github.com/jam2in/arcus-works/issues/832#issuecomment-4474012949

⌨️ What I did

• BopGetArgs 하나로 BTree의 get 연산의 인자를 받던 구조를 연산별 전용 클래스로 분리합니다.
  • BopGetArgs: 단일 BKey 조회 전용 (EFlagFilter, GetOption)
  • BopRangeGetArgs: 범위 조회 전용 (EFlagFilter, offset, count, GetOption)
  • BopSMGetArgs: sort-merge get 전용 (EFlagFilter, count, unique)
• 인터페이스 메서드 시그니처 반영

[jhpark816]

리뷰 완료

[jhpark816]

getARgsWithDrop => getArgsWithDrop

[jhpark816]

50 이라는 제한이 있어야 하나요?

[f1v3-dev]

현재 BopRangeGetArgs를 bop get range 조회와 bop mget에서 공통으로 사용하면서 bop mget의 제약 조건인 1 <= count <= 50이 bop get range 조회에도 적용되는 문제로 보입니다.

고민을 해본 결과 아래와 같이 수정할 수 있을 것 같습니다.

1. BopRangeGetArgs에서는 count >= 1만 검증하고, bopMultiGet() 내부에서만 count <= 50을 검증
2. BopMGetArgs를 별도로 만들고, bop mget 스펙에 맞게 1 <= count <= 50을 검증

참고로 bop mget이 delete/drop 옵션을 지원하지 않는 점까지 고려하면, BopMGetArgs로 분리하는 방향도 괜찮아 보입니다.

[jhpark816]

논의 대상이군요.
그리고, 아래 조건이어야 함을 참고 바랍니다.

• bop range get: count >= 0 : 0이어도 됩니다.
• bop multi get: 1 <= count <= 50

나중에 bop mget에서도 delete/drop 지원할 가능성이 있으므로, 아래와 같이 하는 것이 어떤가 생각합니다.

• BopRangeGetArgs에서는 count >= 0만 검증하고,
• bopMultiGet() 내부에서만 1 <= count <= 50 && no delete/drop을 검증

그리고, DEFAULT 값은 offset = 0, count = 0 이어야 합니다.

[jhpark816]

테스트 목적으로만 사용될 것으로 보이며,
테스트 쪽 코드에 두는 것은 어떤지?

[f1v3-dev]

BopGetArgs.DEFAULT는 eFlag filter 없이 단순 조회하는 케이스가 많다고 판단하여
ElementFlagFilter.DO_NOT_FILTER + GetOption.NONE 조합으로 제공했습니다.

이번 PR의 목적이 BopGetArgs를 연산별 args로 분리하는 것이다 보니
같은 취지로 BopRangeGetArgs.DEFAULT, BopSMGetArgs.DEFAULT도 추가를 한 상태입니다.

다만 BopRangeGetArgs와 BopSMGetArgs는 단순 옵션뿐 아니라
offset, count, unique처럼 조회 결과 범위와 동작에 영향을 주는 값을 포함하여 어색해보이기는 하는데 제거하는 방향이 좋을까요?

[jhpark816]

여기도 논의 대상이군요.
각 연산의 semantic에 따라 인자들의 default 값을 정한다면 아래와 같으니, 참고 바랍니다.

• bop range get에서 offset, count의 default 값은 0이어야 함.
• bop multi get(mget)에서 offset만 default 값이 0이어야 하고, count 값은 입력 필요.
  • count의 default 값을 50으로 정해도 될 것 같음
• bop smget에서 unique만 default 값이 false이어야 하고, count 값은 입력 필요

지금 다시 생각해 보면, 아래 값을 넘기는 것 자체도 어색하지 않나 생각됩니다.

• ElementFlagFilter.DO_NOT_FILTER
• GetOption.NONE
• BopGetArgs.DEFAULT

따라서, 아래와 같이 인자들은 모두 풀어서 표현하고(인자 수가 많지 않음),
필수 인자는 항상 값이 주어져야 하고, 나머지는 Nullable 인자로 생략 시 null을 넘기는 것도
방안이라고 생각합니다. 검토 바랍니다.

// 필수 인자: key, bKey
// Nullable 인자 : eFilter, deleteOption
bopGet(key, bKey, eFilter, deleteOption) // 4가지 호출 형태
- bopGet(key, bKey, null, null);
- bopGet(key, bKey, eFilter, null);
- bopGet(key, bKey, null, deleteOption);
- bopGet(key, bKey, eFilter, deleteOption);

// 필수 인자: key, bKey, offset, count
// Nullable 인자 : eFilter, deleteOption
bopGet(key, from, to, eFilter, offset, count, deleteOption) // 4가지 호출 형태
- bopGet(key, from, to, null, offset, count, null)
- bopGet(key, from, to, eFilter, offset, count, null)
- bopGet(key, from, to, null, offset, count, deleteOption)
- bopGet(key, from, to, eFilter, offset, count, deleteOption)

// 필수 인자: key, bKey, offset, count
// Nullable 인자 : eFilter
bopMultiGet(keys, from, to, eFilter, offset, count) // 2가지 호출 형태
- bopMultiGet(keys, from, to, null, offset, count)
- bopMultiGet(keys, from, to, eFilter, offset, count)

// 필수 인자: key, bKey, count, unique
// Nullable 인자 : eFilter
bopSortMergeGet(keys, from, to, eFilter, count, unique) // 2가지 호출 형태;
- bopSortMergeGet(keys, from, to, null, count, unique)
- bopSortMergeGet(keys, from, to, eFilter, count, unique)

[jhpark816]

1000 값은 MAX_SMGET_COUNT 형태로 상수화하여 사용하는 것은 어떤지?

[f1v3-dev]

1000 이라는 값을 SMGet count 제한이라는 의미를 드러낼 수 있어서 상수화 해도 좋을 것 같습니다.

반영하겠습니다.

[oliviarla]

다음과 같은 형태는 어떤가요?

ArcusFuture<BTreeElement<T>> bopGet(String key, BKey bKey, BopGetArgs args)
// BopGetArgs => eflagfilter, getoption

ArcusFuture<BTreeGetResult<T>> bopGet(String key, BKey from, BKey to, BopRangeGetArgs args)
// BopRangeGetArgs => eflagfilter, offset, count (< 0), getoption(delete|drop)
// BopGetArgs 상속 구조 가능

ArcusFuture<Map<String, BTreeGetResult<T>>> bopMultiGet(List<String> keys, BKey from, BKey to, BopMultiGetArgs args)
// BopMultiGetArgs => eflagfilter, offset, count (1 ~ 50)

ArcusFuture<BTreeSMGetResult<T>> bopSortMergeGet(List<String> keys, BKey from, BKey to, BopSMGetArgs args)
// BopSMGetArgs => eflagfilter, count (1~1000), uniqueness

[jhpark816]

@oliviarla @f1v3-dev

• 인자들을 모두 나열하는 방식과 BopXXXXArgs로 표현하는 방식 중 하나를 응용기술쪽에서 결정해 주세요.
• delete|drop을 나타내기 위해 getOption 보다는 deleteOption이 나을 것 같습니다.

[f1v3-dev]

@jhpark816

DeleteOption.DELETE , DeleteOption.DROP 과 같은 형태는 이름이 겹쳐서 조금 어색해보입니다. "get을 어떤 방식으로 수행할지" 를 나타내는 형태로 GetMode 를 사용하는건 어떤가요?

[jhpark816]

DeleteOption.DELETE , DeleteOption.DROP 과 같은 형태는 이름이 겹쳐서 조금 어색해보입니다. "get을 어떤 방식으로 수행할지" 를 나타내는 형태로 GetMode 를 사용하는건 어떤가요?

아래 형태를 생각했습니다. 즉, delOption이 없으면 null을 주는 인터페이스가 낫지 않나 생각했습니다.

• lopGet(..., delOption = null); // delOption이 null이면 get만 수행한다.
• lopGet(..., delOption.DELETE); // delOption이 주어지면, get 수행하면서 delete 수행한다.
• lopGet(..., delOption.DELETE_AND_DROP_IF_EMPTY); // delete 수행하면서 collection 자체가 empty이면 drop 수행

[oliviarla]

DeletionPolicy나 CleanupPolicy 는 어떠신가요?
그리고, v2 자체가 기존 API에서 특정 인자는 null 타입으로 받는 것의 모호함을 없애는 것도 목적이 있어,null 인자 입력은 지양하고 명확하게 표현하는 것이 좋겠습니다.

[jhpark816]

null 인자 입력은 지양하고 명확하게 표현하는 것이 좋겠습니다.

OK.
그러면, 응용 기술에서 적합한 용어로 선택해 주세요.

[f1v3-dev]

ENUM의 주체가 delete가 아닌 get 동작 방식을 나타내기 때문에 GetMode 가 적절한 것 같다고 판단하여 GetMode로 진행하는 것으로 하겠습니다.

• GetMode.NONE: 단순 Get 수행
• GetMode.DELETE: Get 수행 후 삭제
• GetMode.DROP: Get 수행 후 삭제 및 비어있으면 제거 진행