Skip to content

Introduce StorageBackend abstraction layer by Codex#176

Closed
em3s wants to merge 6 commits intomainfrom
feat/issue-173-engine-storage-backend-codex
Closed

Introduce StorageBackend abstraction layer by Codex#176
em3s wants to merge 6 commits intomainfrom
feat/issue-173-engine-storage-backend-codex

Conversation

@em3s
Copy link
Copy Markdown
Contributor

@em3s em3s commented Feb 5, 2026

Summary

Introduce StorageBackend abstraction layer for engine storage backends.

Closes #173

Task Checklist

  • Step 1: Create interfaces (StorageBackend, StorageBucket, StorageBuckets)
  • Step 2: Create MemoryStorageBucket
  • Step 3: Create MemoryStorageBackend
  • Step 4: Create HBaseStorageBucket
  • Step 5: Create HBaseStorageBackend
  • Step 6: Create DefaultStorageBackendFactory
  • Step 7: Update GraphDefaults
  • Step 8: Update Graph.kt
  • Step 9: Update HBaseOptions.kt
  • Step 10: Update Label classes
  • Step 11: Delete obsolete files
  • Step 12: Run tests

How to Test

  • ./gradlew :engine:test

@em3s em3s changed the title feat(engine): introduce StorageBackend abstraction layer feat(engine): introduce StorageBackend abstraction layer by Codex Feb 5, 2026
@em3s
Copy link
Copy Markdown
Contributor Author

em3s commented Feb 5, 2026

Here's a comment for closing this PR in favor of Claude's PR #175:

Closing this in favor of #175.

Both PRs tackle the same goal — migrating Labels off HBaseTables onto the StorageBackend/StorageBucket abstraction — but take fundamentally different approaches.

#175 (Claude): Compatibility-first. Keeps DefaultHBaseCluster/HBaseTables as a bridge with a deprecated getTable(), leaves existing Label implementations intact, and passes all 431 engine tests.

This: Full cutover. Removes DefaultHBaseCluster/HBaseTables entirely and migrates Labels directly to StorageBuckets + MutationRequest. Cleaner end-state structurally, but only storage-scoped tests have been run — full engine test suite hasn't been validated yet.

The full cutover is where we want to end up eventually, but #175 is the right merge today: lower regression risk with full test coverage, and we can do the legacy cleanup as a follow-up once the new abstraction has proven stable in the broader codebase.

@em3s em3s closed this Feb 5, 2026
@em3s em3s self-assigned this Feb 6, 2026
@em3s em3s changed the title feat(engine): introduce StorageBackend abstraction layer by Codex Introduce StorageBackend abstraction layer by Codex Feb 12, 2026
@em3s em3s deleted the feat/issue-173-engine-storage-backend-codex branch March 1, 2026 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Introduce StorageBackend abstraction layer

1 participant