Replace DefaultHBaseCluster with DefaultStorageBackendFactory#175
Replace DefaultHBaseCluster with DefaultStorageBackendFactory#175
Conversation
Closes #173 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Step 1: Create StorageBackend, StorageBucket, StorageBuckets interfaces Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Step 2: Create MemoryStorageBucket with tests - Implements StorageBucket interface using ByteArrayStore - Add StorageBucketCompatibilityTest as base test class - All 28 tests passing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Step 3: Create MemoryStorageBackend with tests - Implements StorageBackend interface for in-memory storage - All tests passing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Step 4: Create HBaseStorageBucket with tests - Implements StorageBucket interface wrapping HBaseTable - Add supportsIncrement() to compatibility tests for Mock HBase limitations - All available tests passing (some skipped due to Mock HBase) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Step 5: Create HBaseStorageBackend with tests - Implements StorageBackend interface for HBase - Supports HBase 2.4 and 2.5 - Supports Kerberos authentication - All validation tests passing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Step 6: Create DefaultStorageBackendFactory and MockStorageBackend - Factory supports memory, embedded, and hbase backend types - MockStorageBackend wraps HBase MockHTable for testing - All tests passing Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Step 7-8: Update GraphDefaults and Graph.kt to use StorageBackend - GraphDefaults.datastore now uses StorageBackend interface - Graph.kt uses DefaultStorageBackendFactory.initialize/INSTANCE/close - Add getTable() method to StorageBackend for backward compatibility - All existing tests pass Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…ndFactory - Update HBaseOptions.getTables() and getBuckets() to use DefaultStorageBackendFactory - Add getEffectiveNamespace() to use DefaultHBaseCluster namespace as fallback - Update MockStorageBackend to properly handle namespace and tableName parameters - Initialize DefaultStorageBackendFactory in HBaseTestingClusterExtension for tests Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add EmbeddedStorageBackend that wraps HBase testing cluster connection - Update DefaultStorageBackendFactory with initialize(backend) method - Revert MockStorageBackend to use edges table for backward compatibility - Update HBaseTestingClusterExtension to use EmbeddedStorageBackend Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
More explicit naming since it uses HBase MockHTable for storage operations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Each namespace:name combination now gets its own ByteArrayStore instance instead of sharing a single store across all buckets. Added tests: - different buckets are isolated from each other - same namespace and name returns same store Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
More logical package location since it's HBase-specific. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- Add defaultNamespace to DefaultStorageBackendFactory - Update HBaseOptions to use DefaultStorageBackendFactory.defaultNamespace - Update HBaseTestingClusterExtension to pass namespace to factory - Delete DefaultHBaseCluster.kt and compat package Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…ckend Rename to better reflect that this backend wraps the HBase mini cluster for integration testing, distinguishing it from MockHBaseStorageBackend which uses in-memory MockHTable. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
… config - Rename MiniHBaseStorageBackend to HBaseTestingStorageBackend for consistency - Expose connectionMono in HBaseStorageBackend for admin access - Update HBaseDatastoreBindingConfiguration to use DefaultStorageBackendFactory Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Code Review Round 3 - RESOLVED
Tracked separately:
All issues resolved in commit 3c04c7c Reviewed by claude code (opus 4.6) |
- Synchronize DefaultStorageBackendFactory.close() and null out instance - Use Mono.error() instead of throw in MemoryStorageBackend.getTable() - Encapsulate HBaseStorageBackend.connectionMono as private, expose getAdminMono() - Change HBaseOptions log level from INFO to DEBUG for getBuckets()/getTables() Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Too large to review; splitting it up now. |
…-storage-backend-claude # Conflicts: # engine/src/main/kotlin/com/kakao/actionbase/v2/engine/storage/hbase/HBaseStorageBackend.kt
Update test to reference HBaseStorageBackend instead of removed DefaultHBaseCluster class. Apply spotless formatting. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
PR Split PlanThis PR (26 files, +1517/-143) has been split into 3 incremental PRs for easier review: Part 1: Core abstractions + Memory backend — #191Branch:
Part 2: HBase backend + Factory — #192Branch:
Part 3: Consumer migration — This PR (#175)After Parts 1+2 merge to
Merge order |
…-storage-backend-claude # Conflicts: # engine/src/testFixtures/kotlin/com/kakao/actionbase/test/hbase/HBaseTestingClusterExtension.kt # engine/src/testFixtures/kotlin/com/kakao/actionbase/test/hbase/HBaseTestingStorageBackend.kt
Initialize both v2 and v3 DefaultStorageBackendFactory in HBaseTestingClusterExtension to support tests using either API. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Plan: Remove v2 duplicates, wire to v3 StorageBackendPR #175 was started before v3 storage abstractions landed on main (PRs #191/#194/#192), so it created v2-local duplicates. This cleanup removes them and wires v2 engine directly to v3 Key design:
|
| Action | Files | Description |
|---|---|---|
| NEW | 1 | HBaseTablesProvider interface |
| MOD (v3) | 5 | Add HBaseTablesProvider impl + getAdminMono() to backends, widen DatastoreUri regex |
| MOD (v2) | 6 | Switch Graph, HBaseOptions, DatastoreHashLabel, DatastoreIndexedLabel, HBaseTestingClusterExtension, DefaultHBaseClusterTest to v3 imports |
| MOD (server) | 1 | Switch HBaseDatastoreBindingConfiguration to v3 imports |
| DELETE | 17 | v2-local duplicate src (10) + test (7) files |
Files to delete
StorageBackend.kt, StorageBucket.kt, StorageBuckets.kt, DatastoreUri.kt, DefaultStorageBackendFactory.kt, HBaseStorageBackend.kt, HBaseStorageBucket.kt, MockHBaseStorageBackend.kt, MemoryStorageBackend.kt, MemoryStorageBucket.kt + 7 test files
…StorageBackend Delete v2-local duplicate storage classes (StorageBackend, StorageBucket, StorageBuckets, DatastoreUri, DefaultStorageBackendFactory, HBaseStorageBackend, HBaseStorageBucket, MockHBaseStorageBackend, MemoryStorageBackend, MemoryStorageBucket) and their tests, totaling ~1575 lines removed. Add HBaseTablesProvider interface to bridge v2 Labels (which need Mono<HBaseTables> for Filters/CellUtil) to v3 StorageBackend. Implement it in HBaseStorageBackend, MockHBaseStorageBackend, and HBaseTestingStorageBackend. Wire DatastoreHashLabel, DatastoreIndexedLabel, HBaseOptions, and Graph to use v3 DefaultStorageBackendFactory + HBaseTablesProvider instead of the deleted v2 classes. Relax v3 DatastoreUri regex to accept uppercase for backward compatibility with existing data. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… for clarity and consistency Aligns v2 Labels with v3 StorageBackend terminology. Adds @deprecated to HBaseTablesProvider for backward compatibility.
…egation Rename StorageTable.get(List) → getAll and StorageTable.batch(List) → batchAll to avoid JVM type-erasure conflicts with HBaseTable methods. HBaseStorageTable now implements both StorageTable and HBaseTable by table, keeping all v2 HBaseTable call sites unchanged. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…ch for consistency Align method names across StorageTable implementations to improve clarity and eliminate unnecessary verbosity. Update corresponding test cases to reflect the changes.
…atchAll Resolve JVM type-erasure conflicts so HBaseStorageTable can implement both StorageTable and HBaseTable by delegation. StorageTable method names (get/batch) remain unchanged. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
Replace
DefaultHBaseClusterwithDefaultStorageBackendFactory+HBaseStorageBackend(both already on main via PRs #191, #194, #192).Before:
DefaultHBaseCluster-- a monolithic singleton bundling connection management, mock branching, and table access.After:
DefaultStorageBackendFactorydispatches to pluggable backends (HBaseStorageBackend,MemoryStorageBackend,MockHBaseStorageBackend), each implementing theStorageBackendinterface. The HBase backend can now be swapped for any otherStorageBackendimplementation.Storage backend series: PR #191 -> PR #194 -> PR #192 (all merged) -> this PR
Known issue
This PR was started before the v3 abstractions landed on main, so it created v2-local duplicates (
StorageBucket,DatastoreUri,DefaultStorageBackendFactory, etc.) instead of using the v3 classes directly. These should be removed and replaced with v3 imports.v2/.../StorageBackendengine.storage.StorageBackendv2/.../StorageBucket/StorageBucketsengine.storage.StorageTablev2/.../DatastoreUriengine.storage.DatastoreUriv2/.../DefaultStorageBackendFactoryengine.storage.DefaultStorageBackendFactoryv2/.../HBaseStorageBackendengine.storage.hbase.HBaseStorageBackendv2/.../MockHBaseStorageBackendengine.storage.hbase.MockHBaseStorageBackendv2/.../MemoryStorageBackendengine.storage.memory.MemoryStorageBackendTest plan
./gradlew :engine:buildpasses