Wrapping Existing Code without Anonymous Functions

When you work with a relational database, sometimes writing safe and correct programs requires you to bundle up several database changes into a single transaction which you can apply or reject atomically.

In DBIx::Class, that's through the txn_do method, which looks something like:

$db->txn_do(sub
{
    # make changes here
    ...
    # make other changes here
});

Pass an anonymous function to this method. The method will start a transaction, invoke the anonymous function, then commit or roll back the transaction depending on the success or failure of the anonymous function. It's a good pattern, because the anonymous function can do arbitrary things; the transactional wrapper imposes very few requirements on it.

(PSGI follows a similar pattern.)

In a recent commit on a client project, I wanted to add transactional semantics to a DDL change. In effect, if creating a custom database view failed, I wanted to roll back the change without replacing an existing view. If replacing an existing view succeeded, I wanted to commit it.

I could have used the anonymous function pattern, but I chose a different approach:

sub run_in_transaction {
    my ($self, $method_name, $args) = @_;

    $self->begin_work;
    local $@;
    my $status = eval { $self->$method_name( @$args ); $self->commit; 1 };

    return $status if $status;
    $self->rollback;
    die $@;
}

Instead of wrapping up the other code in a transactional block, to use this method you pass the name of another method in the same class to call along with an array reference of arguments to pass to that method.

Is this easier to use? In some circumstances, but it also has its limitations. It only works for methods on the same object. It only works for single statements. When those conditions are true, I think this code is clearer> than the anonymous function approach.

Will it last in our code after a few more rounds of refactorings and revisions? I don't know—but it solved the DDL update problem elegantly enough for now.

DBIC can't get away with anything this simple, because it needs to provide a consistent and coherent solution without imposing artificial limitations. This code has no need for that generality yet. I could just as well have used the anonymous function, and I may in the future, but for now this satisfies my needs. It's just another technique which you may find useful in specific circumstances.