Re: PATCH porting.pod First Mystery
Stas Bekman [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: In private mail Stas Bekman [EMAIL PROTECTED] writes: oops, that should be the modperl list... at modperl-docs we discuss mostly site/docs techical issues and there are very few people on this list to get enough exposure for this kind of feedback request. Patch for The First Mystery section of the mod_perl porting guide as per my conversation with Stas at YAPC::Europe::2003. Takes out the suggestion of creating a Perl4-style library in the same directory as a means to port CGI scripts. Replaces it with something simpler and more reliable. Nice, but: +The easiest and the fastest way to solve the nested subroutines +problem is to change Cmy to Clocal Cour for all variables for +which you get the warning. The Chandler subroutines are never ... [...] + local our $counter = 0; local our? That should be either local or our, but not both. No. Do I miss something? Yes. (I tried to explain this in Paris but I was in danger of causing you to miss lunch completely). local() and our() do two quite separate and complementary things. our() (in effect) declares a lexically scoped alias for a package variable. local() restores the old value of a package variable (usually undef) at the end of the current lexical scope. The two combined therefore give a package variable two of the most useful properties of a lexical one. Of course a real lexical variable doesn't really become undefined when it does out of scope - it really becomes anonymous, and iff there are no remaining (unweakened) references it then gets GCed. But for file-scoped lexicals in the main script file the difference is usually not that important. Both effectively get killed at the point where global destruction would have taken place. The rest looks good, but that's not the simplest solution as you have to modify the variables. Is there a simpler one? For a typical script with say half a dozen variables the would not remain shared the local our solution requires a dozen keystokes on each of half a dozen lines. Granted, the original simplest solution has its troubles. The original simplest solution involved finding (and subsequently maintaining) a globally unique filename then splitting the program in to two parts. Thereafer you have to maintain two files even on CGI servers. I would contend that this simple solution is not simple. If you are going to all that troble you may as well to the extra 804.65m and produce a proper mod_perl handler and a small wrapper to make it work also in a CGI environment. Also, as of mod_perl2, the simple solution is not even, as it stands, a solution as it relied on the script being in the CWD. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::Session and pnotes
I am trying to retrieve/create an Apache::Session object for a given
user in the authentication phase, so the following handlers have them
available via pnotes. Sessions are stored in an Oracle database.
It seems, however, that Apache::Session objects stop being stored when I
put the session in pnotes() with a code analogous to this:
my $r = Apache::Request-instance(shift);
tie my (%session), 'Apache::Session::Oracle', undef,
{Handle = $class-dbh(), Commit = 1};
$r-pnotes(session = \%session);
Is there any gotcha regarding the kind of objects that can be passed
with pnotes? Or do you know what can be happening anyway if not?
-- fxn
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::Session extra record not write to Mysql db.
i am experiencing a weird problem with the use of apache::session::mysql
before i had three fields in table sessions : a_session,id,time in the DB.
and updating table etc from the program was working just fine. however, after i added
one more
field (username) to the sessions table through phpmysql, updating it in the program
seems has no effect on the username record. no problem on others.
i am sure the username is present in the program. and i can add username record by
hand through
phpmysql without problem. so i dont think it's lack of database rights.
i also add a test record which just get timestamp. but it still don't get updated.
here is code.
sub set_cookie {
my $self = shift;
my $sid = shift;
$sid ||= '';
my %session;
_open_db($self) unless $self-{DBH};
eval {
tie %session, Apache::Session::MySQL, $sid,
{Handle = $self-{DBH}, LockHandle = $self-{DBH} };
};
croak(creating cookie error: [EMAIL PROTECTED]) if ($@);
$sid = $session{'_session_id'};
my $uname = get_uname($self);
$session{'test'} = time();## this doesn't update 'test'
$session{'uname'} = $uname if $uname; ## this doesn't update 'uname'
$session{'time'} = time();## this updates 'time' record
my $cookie = Apache::Cookie-new(
$self-{request},
-name = 'ID',
-value = $sid,
-expires = $self-{CONFIG}-{cookie}-{cookie_expire},
);
$cookie-bake;
return $self-{request};
}
i feel i may have done something stupid but i couldn't find it...
Regards,
Qiang
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
