You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Randolf Richardson <ra...@modperl.pl> on 2011/02/19 22:30:42 UTC
Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)
> On Sat, Feb 12, 2011 at 3:26 PM, Thomas den Braber <th...@delos.nl> wrote:
>
> > On linux I also had never any problem with Reload. But on Linux I always
> > run Apache with prefork MPM (I have not tested with Worker MPM on Linux
> > yet), on Windows there is only Worker MPM, can there be a relation between
> > the reload problem and the Worker MPM?
>
> Not likely. Threads don't share any data in Perl unless you tell them
> to. The things Reload has trouble with tend to be sneaky programming
> tricks, like auto-generated methods and classes.
I never use the auto-generation feature in DBIx::Class from the web-
server side -- I always generate these from a shell prompt first and
then install them.
I know there are a lot of people using DBIx::Class with auto-
generation, probably because it's easier, but if something changes in
the database then the class will change which could lead to some
developers wondering what went wrong.
It's interesting to know that auto-generated code is a problem, and
this is providing me with some insight into why some DBIx::Class
users have been telling me that mod_perl (all versions) is so
terrible (I didn't experience the problems they described, and your
comment has shed some light on a possible reason).
Thanks!
Randolf Richardson - randolf@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.inter-corporate.com
Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)
Posted by Perrin Harkins <pe...@elem.com>.
On Sat, Feb 19, 2011 at 4:30 PM, Randolf Richardson <ra...@modperl.pl> wrote:
> It's interesting to know that auto-generated code is a problem, and
> this is providing me with some insight into why some DBIx::Class
> users have been telling me that mod_perl (all versions) is so
> terrible (I didn't experience the problems they described, and your
> comment has shed some light on a possible reason).
The sort of trouble I've seen with auto-generated code has to do with
changing subs in ways that perl is unable to deal with without
restarting the interpreter. For example, if you define a constant
(which is a sub with a prototype in perl), and then change it and try
to reload the module, you will have trouble. If you change the
inheritance of a class, you may also have trouble.
These things would be exactly the same under FastCGI or any other Perl
environment. The problem is that Perl can't really reload classes on
the fly, and tools that try to do it are simply deleting things from
the symbol table and loading the code again. Sometimes this works and
sometimes it doesn't, and the trickier your code is, the more likely
it is to not work.
Take people's prejudices against mod_perl with a grain of salt. There
are many misconceptions out there about mod_perl, but when you run it
in the recommended configuration (with a proxy server in front) there
is very little real difference from FastCGI and friends.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)
Posted by Fred Moyer <fr...@redhotpenguin.com>.
On Sat, Feb 19, 2011 at 1:30 PM, Randolf Richardson <ra...@modperl.pl> wrote:
> It's interesting to know that auto-generated code is a problem, and
> this is providing me with some insight into why some DBIx::Class
> users have been telling me that mod_perl (all versions) is so
> terrible (I didn't experience the problems they described, and your
> comment has shed some light on a possible reason).
For what it is worth, I've been using DBIx::Class with mod_perl for
over five years now, and have not run into any problems worth
mentioning. I separate my model code from my request handlers though,
and increment the dependency version in my Makefile.PL, so I do a
server restart whenever I update one of the dependent modules. The
code separation causes the development process to take more time, but
the code is usually better quality in my opinion.
I build a model library with DBIx::Class autoloaders, to which I add
custom methods for my model classes. Takes a lot of the book keeping
work out of making accessor methods, etc.
Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)
Posted by Perrin Harkins <pe...@elem.com>.
On Sat, Feb 19, 2011 at 4:30 PM, Randolf Richardson <ra...@modperl.pl> wrote:
> It's interesting to know that auto-generated code is a problem, and
> this is providing me with some insight into why some DBIx::Class
> users have been telling me that mod_perl (all versions) is so
> terrible (I didn't experience the problems they described, and your
> comment has shed some light on a possible reason).
The sort of trouble I've seen with auto-generated code has to do with
changing subs in ways that perl is unable to deal with without
restarting the interpreter. For example, if you define a constant
(which is a sub with a prototype in perl), and then change it and try
to reload the module, you will have trouble. If you change the
inheritance of a class, you may also have trouble.
These things would be exactly the same under FastCGI or any other Perl
environment. The problem is that Perl can't really reload classes on
the fly, and tools that try to do it are simply deleting things from
the symbol table and loading the code again. Sometimes this works and
sometimes it doesn't, and the trickier your code is, the more likely
it is to not work.
Take people's prejudices against mod_perl with a grain of salt. There
are many misconceptions out there about mod_perl, but when you run it
in the recommended configuration (with a proxy server in front) there
is very little real difference from FastCGI and friends.
- Perrin