bradcathey has asked for the wisdom of the Perl Monks concerning the following question:

Fellow Monasterians,

This is a strange one and I'm at a loss after lots of experimenting.

I'm using CGI::Application::Plugin::Session in combo with FlexMySQL to save sessions to the DB. The following code does not save the account_id to the session.

$self->session->param('account_id' => $account_id);

[download]

But when I add some debugging code or Dumper after the line, e.g.,

$self->session->param('account_id' => $account_id);

open (DEBUG, ">>/home/bradc/debug/debug.txt") or die "errors: $!";
print DEBUG "acct_id: ".$self->session->param('account_id')."\n";
close DEBUG;

[download]

everything is fine—the account_id has a value.

Does this have something to do with the printing? Is there a simple explanation for this that I'm not seeing. Thanks.


—Brad
"The important work of moving the world forward does not wait to be done by perfect men." George Eliot

Replies are listed 'Best First'.
Re: CGI::App::Session param not getting saved
by wfsp (Abbot) on Jan 24, 2007 at 08:23 UTC
    A wild stab in the dark.

    When I had a similar problem with CGI::Application::Plugin::Session I was able to trace it back to not having the right version of Scalar::Util. Recent versions of which have a refaddr method which is used by recent versions of CGI::Session. I think it was at the time serialising objects became possible which makes some sense.

    S::U is not a pure Perl module so I wasn't able to 'install' (copy) the module to my hoster. A bit of digging showed that installing an older version of C::S that doesn't use Scalar::Util->refaddr was a possible way forward. I haven't tried it myself because by this time I had found another work around.

    The horrible story: CGI::Session/MySQL dependancy/version woes.
    Updated: Added link.

[reply]
Re: CGI::App::Session param not getting saved
by Anonymous Monk on Jan 24, 2007 at 00:23 UTC
    How do you know the account_id isn't saved? Please explain in detail.
[reply]

      Good question (sorry, I'm not sure how much to expound on this one).

      I know it isn't being saved because I am able to view the contents of the record of the session in MySQL. Those records without any print statement show no 'account_id' language at all. Those with the print statements show account_id => 2, or whatever number.

      Hope this helps


      —Brad
      "The important work of moving the world forward does not wait to be done by perfect men." George Eliot
[reply]
[d/l]
[select]
        bradcathey,
        Are you calling the flush() method explicitly or are you letting the object do it for you in DESTROY? I ask because the docs refer to a ticket complaining that in some cases, session data is not saved unless called explicitly. It is interesting that the behavior is inconsistent.

        Try flush() in the teardown method.

        Cheers - L~R

[reply]

Back to Seekers of Perl Wisdom