perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Swartz <swa...@pobox.com>
Subject Re: a better way to recognize module changes
Date Fri, 11 Sep 2009 22:37:14 GMT

> On Fri, Sep 11, 2009 at 3:11 PM, Jonathan Swartz <swartz@pobox.com>  
> wrote:
>> It seems like it's available separately in Apache-Reload  
>> distribution:
>> http://cpan.uwinnipeg.ca/dist/Apache-Reload
>>
>> But it's already pretty much a straw-man option for me. :)
>
>>>> Problem: some modules fail to reload properly. Sometimes the  
>>>> failure
>>>> is intermittent, depending on the order of module loading and other
>>>> esoteric details. Moose and ORM modules seem particularly prone to
>>>> reload failures. For me, this level of unpredictability makes
>>>> *::Reload too frustrating to use.
>
> I've run into issues with reloading ORM based modules such as when I
> change my DBIx::Class based schema.  I get an inconsistent hierarchy
> error from Class::C3.  So in those cases a server restart is required.
>
> However, if your model layer is abstracted from mod_perl, you should
> be able to develop against your model layer using tests, and then
> install your upgraded model and restart Apache then.  The behavior
> where I encounter problems reloading changes to ORM modules has
> enforced a good separation of model (ORM) and controller( mod_perl )
> code in my application.

I'm all for TDD, to be sure, but in practice not everything -  
especially with controller and view-specific modules - is going to be  
developed in this way.

I've often exhorted Mason developers to move things out of components  
into modules, but a real objection to that has been the server restart  
cost, and I've never had a good answer for it. Mason components (like  
TT templates, etc.) can pretty much always be reloaded without  
restart, which I expect is one reason why so much code ends up there.

Jon


Mime
View raw message