Problem
The StorageBucket interface — which is meant to be a storage-agnostic abstraction — imports and returns HBaseRecord from com.kakao.actionbase.core.storage. This leaks HBase-specific naming into the abstraction contract. Any future backend implementor (e.g., Redis, DynamoDB, SlateDB) must work with a type named after HBase.
Context
Identified during code review round 3 of PR #175 (StorageBackend abstraction layer, closes #173).
Affected interface methods in StorageBucket.kt:
fun get(keys: List<ByteArray>): Mono<List<HBaseRecord>>fun scan(...): Mono<List<HBaseRecord>>
HBaseRecord lives in core module (com.kakao.actionbase.core.storage.HBaseRecord) and is a simple key-value pair. Renaming it to StorageRecord would make the abstraction truly backend-agnostic.
Proposed Approach
- Rename
HBaseRecord → StorageRecord in core module
- Update all usages across
core, engine, and server modules
- Ensure all tests pass
This is a straightforward rename refactor with no behavioral changes.
Created by claude code (opus 4.6)
Problem
The
StorageBucketinterface — which is meant to be a storage-agnostic abstraction — imports and returnsHBaseRecordfromcom.kakao.actionbase.core.storage. This leaks HBase-specific naming into the abstraction contract. Any future backend implementor (e.g., Redis, DynamoDB, SlateDB) must work with a type named after HBase.Context
Identified during code review round 3 of PR #175 (StorageBackend abstraction layer, closes #173).
Affected interface methods in
StorageBucket.kt:fun get(keys: List<ByteArray>): Mono<List<HBaseRecord>>fun scan(...): Mono<List<HBaseRecord>>HBaseRecordlives incoremodule (com.kakao.actionbase.core.storage.HBaseRecord) and is a simple key-value pair. Renaming it toStorageRecordwould make the abstraction truly backend-agnostic.Proposed Approach
HBaseRecord→StorageRecordincoremodulecore,engine, andservermodulesThis is a straightforward rename refactor with no behavioral changes.
Created by claude code (opus 4.6)