in reply to Re: RFC: Transactions.pm
in thread RFC: Transactions.pm

but it also means that there may only be one object in the transaction.

See my example in another node in this thread about how you can easily write a wrapper package to allow this.

sub code (&) {return $_[0]}

Why not just use sub instead of code and call like transaction [ $foo, $bar ], sub { ... };?

Another small fix is that the "commit not safe after errors, transaction rolled back" message should be croak()ed, not die()d.

Not really. Note that $@ already contains the caller's filename and line number. I think this looks very nice: 

died at foo.pl line 13.
commit not safe after errors, transaction rolled back at Transactions.
+pm line 123.

[download]

I wanted a (&) prototype to allow the sub keyword to be left out. So I tried several solutions to select a transaction capable object, $T being my most recent try.

But the more I think about it, typing sub isn't so bad. As you say, if you simply supply the dbh to transaction(), nested transactions can be supported.

I'll whip up a third version soon.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Replies are listed 'Best First'.
Re: Re: Re: RFC: Transactions.pm
by Jenda (Abbot) on Apr 28, 2003 at 13:38 UTC

    1) Because 

    transaction $bdh => code{ ... }

    [download]
    reads better than 
    transaction $bdh, sub { ... }

    [download]
    . That's the only reason.

    2) Well, it may contain the filename&linenumber of the original error message, but not of the place where the transaction ends and where therefore it's commited or rolled back. I think it makes more sense to append the position of the closing brace of the transaction block than some line within Transaction.pm. Try to throw an exception within a second level transaction. You'll end up with something like:

    Some error
commit not safe after errors, transaction rolled back at Transactions.
+pm line 123
commit not safe after errors, transaction rolled back at Transactions.
+pm line 123

    [download]
    Not very helpfull I'd think :-)

    Here is the script I used to test my version of the module:

    Read more... (1474 Bytes)

    Jenda
    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
       -- Rick Osborne

    Edit by castaway: Closed small tag in signature

[reply]
[d/l]
[select]
      Of course you can write that as 
      transaction $dbh => sub { ... };

      [download]
      as well. You know, thinking about this topic, it occured to me that this is where Perl6 user exposed parsing would allow us to superimpose such features on the language seamlessly, without all the caveats inherent to Perl5 solutions.

      Makeshifts last the longest.

[reply]
[d/l]

        Yeah I know. It's the sub that looks kinda strange there.

        You are probably right about Perl6. I've tried to read a few Apocalypses&Exegei, but do not remember much. I need something to experiment with to grok such stuff.

        Jenda
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
           -- Rick Osborne

        Edit by castaway: Closed small tag in signature

[reply]
[d/l]

        it occured to me that this is where Perl6 user exposed parsing would allow us to superimpose such features on the language seamlessly, without all the caveats inherent to Perl5 solutions.

        You won't have to change the grammar or have a "parsed" trait on an operator. Every block is a closure, so something like this will work: 

        multi transaction (Object $object, &block) {
    ...;
    block();
    ...;
}

        [download]
        transaction $dbh -> {
    ...
}

        [download]
        (Note: this is probably wrong, but I can't check it since I don't have a working Perl 6 interpreter :)

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

[reply]
[d/l]
[select]

In Section Meditations