"Chas. Owens" <chas.ow...@gmail.com> writes:

> State variables are just like my variables but with a different lifetime,
> so it is safe (assuming it would be safe to use my variables that life for
> the lifetime of the program).

Thanks!

What's a safe alternative?  If you need to have values remembered across
multiple calls of functions, you got to somehow store these values,
either in state variables, or otherwise in such a way that they are
inaccessible to other parts of the program.  The difference lies in the
ease, reliability and thus safety of retrieving the values, not in the
safety of the variables holding them.

The variables don't change their names across multiple calls of the
functions, and I would ask where the safety lies: In the names of the
variables, in the values you need them to remember or in the
accessability of their values?

> In this case, what happens if you lose database access and then
> reconnect?

When the connection goes away, the program is terminated, yielding an
error message?

I've had that happen in rare cases which weren't easy to fix because the
cause was hard to find.  It would just say that the mysql server has
gone away, for no apparent reason.

So the program does not reconnect --- or does it, without my knowledge
and without being terminated?

If it reconnects, is there a difference between creating statement
handles outside of functions using them and passing them as arguments
and creating statement handles within the functions using them, storing
them in state variables?

> What happens if you have two database handles?

That is awkward ;)

> Your statement handles are going to be bad or refer to the wrong
> DB.

not when I pass the right database handle to the function creating a
statement handle

> What you really want here is the $dbh->prepare_cached method call. It
> will correctly handle both scenarios and avoid reparsing the SQL.

Hmm.  That might work, and it would be better.


I haven't considered re-connecting at all.  That just hasn't come up yet
with what I've been doing with DBI so far.

How do you make a program re-connect, and in such a way that it is safe
to try that?  Like I wouldn't want it to try re-connecting indefinitely.

How do you even detect a disconnection and its reason?  Like I would
want to re-connect when the mysql server has disconnected the program
due to inactivity but not when it's disconnected due to an error in the
program.

And I need to figure that out for SNMP sessions, too.  Can they even get
disconnected?


> On Mon, Apr 24, 2017, 20:02 lee <l...@yagibdah.de> wrote:
>
>> Hi,
>>
>> is it ok to assign an object to a state variable?  Or does doing so
>> involve a chance of causing problems because objects are not supposed or
>> designed to be used with the state-feature?
>>
>> Example:
>>
>>
>> use feature qw(state);
>> use DBI;
>>
>>
>> sub foo {
>>   my ($dbh, $q, $finish) = @_;
>>
>>   state $sth = $dbh->prepare("SELECT foo FROM bar WHERE baz = ? LIMIT 1");
>>   if($finish) {
>>     $sth->finish();
>>     return 0;
>>   }
>>
>>   $sth->execute($q);
>>   my ($ret) = $dbh->selectrow_array($sth);
>>
>>   return $ret;
>> }
>>
>>
>> #
>> # do some stuff like connecting to database etc.
>> #
>>
>> foreach (1..10) {
>>   my $z = foo($dbh, $_, 0);
>>   #
>>   # do more stuff with $z
>>   #
>>   my $x = foo($dbh, $z, 0);
>>   #
>>   # ...
>>   #
>> }
>>
>> foo($dbh, 1);
>> exit 0;
>>
>>
>> I think it would be nicer to keep statement handles ($sth) contained within
>> the functions that use them instead of defining them in the main part and
>> handing them over to the functions.  Their very purpose is that you define
>> a handle once and use it multiple times, thus saving the overhead of
>> interpreting the statement every time it is used.
>>
>> But can I safely use a state-variable like this?  If not, then what?
>>
>>
>> --
>> "Didn't work" is an error.
>>
>> --
>> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
>> For additional commands, e-mail: beginners-h...@perl.org
>> http://learn.perl.org/
>>
>>
>>

-- 
"Didn't work" is an error.

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to