Implementing Transaction Rollback for Database Operations in Jest

Database transactions are crucial for maintaining data integrity, ensuring that a series of operations either all succeed or all fail. In testing, simulating this transactional behavior is vital to verify that your application correctly handles both successful and failed operations. This challenge focuses on implementing a mechanism to simulate transaction rollback within your Jest tests.

Problem Description

Your task is to create a system that simulates database transactions with rollback capabilities within your Jest test environment. You will need to develop a way to:

1. Start a transaction: Mark the beginning of a sequence of database operations.
2. Perform operations: Simulate common database operations like INSERT, UPDATE, and DELETE. These operations should be recorded within the current transaction.
3. Commit a transaction: If all operations within a transaction are successful, make them permanent.
4. Rollback a transaction: If any operation within a transaction fails, undo all operations that were part of that transaction, leaving the database in its original state.

The goal is to have a test utility that allows you to wrap asynchronous database operations (or their simulated equivalents) in a transactional block. If the block's code throws an error, the simulated changes should be discarded. If the block completes successfully, the changes should be applied.

Examples

Example 1: Successful Transaction

// Assume a simple in-memory "database" store:
// const mockDb: Record<string, any> = { users: {} };

// Function to simulate database operations
async function addUser(id: string, name: string): Promise<void> {
  // Simulate async operation
  await new Promise(resolve => setTimeout(resolve, 10));
  mockDb.users[id] = { id, name };
}

async function updateUser(id: string, newName: string): Promise<void> {
  await new Promise(resolve => setTimeout(resolve, 10));
  if (!mockDb.users[id]) {
    throw new Error(`User with ID ${id} not found`);
  }
  mockDb.users[id].name = newName;
}

// Test setup
describe('Transaction Rollback', () => {
  let mockDb: Record<string, any>;

  beforeEach(() => {
    mockDb = { users: {} };
  });

  it('should successfully commit a transaction', async () => {
    await transactional(async () => {
      await addUser('user1', 'Alice');
      await updateUser('user1', 'Alicia');
    }, mockDb);

    // Expected state after commit
    expect(mockDb.users['user1']).toEqual({ id: 'user1', name: 'Alicia' });
  });
});

Explanation: The transactional function should wrap the operations. Since addUser and updateUser complete without errors, the changes should be applied to mockDb.

Example 2: Transaction Rollback on Error

// Using the same mockDb, addUser, and updateUser functions from Example 1.

describe('Transaction Rollback', () => {
  let mockDb: Record<string, any>;

  beforeEach(() => {
    mockDb = { users: {} };
    // Pre-populate for the rollback scenario
    mockDb.users['user1'] = { id: 'user1', name: 'Alice' };
  });

  it('should rollback a transaction on error', async () => {
    let errorThrown = false;
    try {
      await transactional(async () => {
        await updateUser('user1', 'Alicia');
        // This will throw an error, causing a rollback
        await updateUser('user2', 'Bob');
      }, mockDb);
    } catch (error) {
      errorThrown = true;
      // Expected error message
      expect(error).toBeInstanceOf(Error);
      expect(error.message).toBe('User with ID user2 not found');
    }

    expect(errorThrown).toBe(true);
    // Expected state after rollback: original state should be preserved
    expect(mockDb.users['user1']).toEqual({ id: 'user1', name: 'Alice' });
    expect(mockDb.users['user2']).toBeUndefined();
  });
});

Explanation: The updateUser('user2', 'Bob') call will throw an error because user2 does not exist. The transactional function should catch this error, prevent any committed changes from the transaction (including the first updateUser call), and re-throw the original error. The mockDb should remain in its state before the transaction began.

Example 3: Nested Transactions (Optional, for advanced consideration)

// Consider how your system would handle nested transactions.
// For this challenge, assume a simpler model where the outermost transaction dictates rollback.

Constraints

• The simulated database should be an in-memory object or structure. You do not need to interact with a real database.
• The rollback mechanism should be implemented as a utility function (e.g., transactional(callback, db)).
• The callback function passed to transactional will be an async function.
• All simulated database operations (addUser, updateUser, etc.) within the callback should also be async and may reject promises with errors.
• The rollback should correctly restore the state of the simulated database to exactly what it was before the transactional block started. This means deep copying the database state at the start of the transaction.

Notes

• Think about how to capture the state of your simulated database before any operations within the transaction begin.
• Consider how to store the operations performed within a transaction so they can be undone if a rollback is necessary.
• The transactional utility should handle both successful completion and error propagation from the callback.
• For simplicity, you can assume synchronous operations within the callback are acceptable if they don't need to be async, but designing for async operations makes the simulation more realistic.
• This challenge is about the pattern of transaction management and rollback in testing, not about database internals.