feat(db): Create generic transaction handler BED-7079

[cweidenkeller]

Description

Describe your changes in detail

Motivation and Context

This provides a generic inter face for registering DB handlers and also providing simple transactrions.

Resolves BED-7079

Why is this change required? What problem does it solve?

Currently we have a need for simple transactions that wrap our existing DB handlers

How Has This Been Tested?

Integration testing

Screenshots (optional):

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• I have met the contributing prerequisites
  • Assigned myself to this PR
  • Added the appropriate labels
  • Associated an issue: Issues and Pull Requests README #672
  • Read the Contributing guide: https://github.com/SpecterOps/BloodHound/wiki/Contributing
• I have ensured that related documentation is up-to-date
  • Open API docs
  • Code comments (GoDocs / JSDocs)
• I have followed proper test practices
  • Added/updated tests to cover my changes
  • All new and existing tests passed

Summary by CodeRabbit

Release Notes

• New Features

  • Implemented generic transaction abstraction layer enabling contextual database operations with rollback and error handling capabilities.
  • Added support for nested transactions and context cancellation during database operations.

• Tests

  • Added comprehensive integration tests covering transaction commit, rollback, multiple operations, and nested transaction scenarios.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The changes introduce a generic transaction abstraction layer for database operations. BloodhoundDB now embeds a TransactableDB wrapper that manages transactional contexts through pluggable executor implementations. New integration tests validate transaction semantics including commit, rollback, nested transactions, and context cancellation.

Changes

Cohort / File(s)	Summary
Database Transaction Abstraction cmd/api/src/database/transactions.go	Introduces generic transaction interfaces: Transactable[T] for transaction capability, TransactionExecutor[D] for pluggable execution strategy, and TransactableDB[T, D] struct that manages transactions via executor delegation. Adds concrete gormExecutor for GORM-based transaction handling with context support.
BloodhoundDB Integration cmd/api/src/database/db.go	Refactors BloodhoundDB struct to embed TransactableDB[*BloodhoundDB, *gorm.DB] instead of concrete *gorm.DB field. Updates NewBloodhoundDB to initialize the TransactableDB wrapper with handle, executor, and transaction factory function.
Transaction Integration Tests cmd/api/src/database/transactions_integration_test.go	New integration test suite validating transaction semantics: commit/rollback behavior, multiple operations, partial rollback isolation, context cancellation handling, and nested transaction scenarios. Tests exercise BloodhoundDB.Transaction() with asset group operations.

Sequence Diagram

sequenceDiagram
    participant App as Application
    participant TxDB as TransactableDB<br/>[*BloodhoundDB, *gorm.DB]
    participant Exec as gormExecutor
    participant Gorm as GORM<br/>(*gorm.DB)
    
    App->>TxDB: Transaction(ctx, fn)
    TxDB->>Exec: RunTransaction(ctx, handle.db, fn)
    Exec->>Gorm: WithContext(ctx)
    Exec->>Gorm: BeginTx()
    
    rect rgb(200, 220, 240)
    Note over Exec,Gorm: Transactional Scope
    Exec->>TxDB: withTxFn(txHandle)
    TxDB-->>Exec: txDB (*BloodhoundDB)
    Exec->>App: fn(txDB)
    App->>Gorm: Operations (Create, etc.)
    Gorm-->>App: Results
    end
    
    alt Commit
        Exec->>Gorm: Commit()
        Gorm-->>Exec: ✓ Success
    else Rollback
        Exec->>Gorm: Rollback()
        Gorm-->>Exec: ✓ Rolled back
    end
    
    Exec-->>TxDB: Result / Error
    TxDB-->>App: Result / Error

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 With whiskers twitching, code takes flight,
A generic dance of transactions so right!
Rollback, commit, nested and true,
The rabbit's abstraction sees it all through!
From GORM to executor, the pattern's now clear,
Database workflows simplified here! 🌿

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description check	⚠️ Warning	PR description is incomplete with missing required sections and minimal detail in provided sections.	Add detailed descriptions for each section: expand Description, provide specific reasons for the change, detail the integration tests performed, and clarify how functionality was tested.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'feat(db): Create generic transaction handler BED-7079' clearly and concisely describes the main change: adding a generic transaction handler to the database layer.

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cweidenkeller]

My plan is to refactor this a bit I went a little ham on the generics the implementation is confusing and brittle.