Re: example of really weird caching (or whatever) problem

b == bmetcalf(at)cash(dot)us(dot)nortel(dot)com writes:

b> d == dev(at)archonet(dot)com writes:

b> d> Brandon Metcalf wrote:
b> d> > Yep, it seems that's the problem. If I pass in $table and use a
b> d> > lexical variable defined inside do_delete(), the problem goes away.
b> d> > So, this is where my understanding of how triggers work lacks. For a
b> d> > given session, each execution of a trigger isn't completely
b> d> > independent?

b> d> Nothing to do with triggers - it's all to do with your Perl code.

b> I respectfully disagree because if I don't execute a DELETE on foo2 as
b> shown in my original email, the problem doesn't occur. Somewhere in
b> the trigger execution it's remembering the first table on which the
b> trigger fired. So, the information about foo2 is coming from
b> somewhere and it's in the Perl code. In other words, I performing two

That should read it's _not_ in the Perl code.

b> different DELETEs which cause two different invocations of the same
b> trigger.

b> d> #!/usr/bin/perl

b> d> sub foo {
b> d> my $x = shift;
b> d> print "foo x = $x\n";
b> d> bar();
b> d> return;

b> d> sub bar {
b> d> print "bar x = $x\n";
b> d> }
b> d> }

b> d> foo(1);
b> d> foo(2);
b> d> exit;

b> d> $ ./perl_example.pl
b> d> foo x = 1
b> d> bar x = 1
b> d> foo x = 2
b> d> bar x = 1

b> d> If you use warnings it'll tell you about it too with this example.

--
Brandon