[Dancer-users] Plugin::Database failed on reconnect

[damien krotkine]

Hi,

I think there may be some other cases where we would hit this issue :

What if the user has a global data structure, and passes it to the
template in the tokens. It'll be passed as reference, and we'll be in
the same issue, the Escape plugin will change the original data.
Consider this pseudo example :

my $global_hash = { foo => "&bar" } ;

get 'some/route' => sub {  template ( {  global_hash => $global_hash } ) };


I know it's bad design to use a global variable like that, but you get
the idea :)

So, instead of cloning only the things Dancer purposely adds to the
tokens, meybe either :
- Dancer should clone the whole token hash (bad idea in my opinion,
you want to be able to pass a dbh or a coderef)
- Dancer escape plugin should take care of cloning the things he's changing
- Or at least we should document that in Dancer, and in the excape plugin

Any thought ? Or am I too picky  ? :)

On 12 April 2012 12:20, David Precious <davidp at preshweb.co.uk> wrote:
> On Thu, 12 Apr 2012 10:41:05 +0100
> David Precious <davidp at preshweb.co.uk> wrote:
>
>> However, as Dancer::Config->settings returns us the actual hashref,
>> we're storing a reference; D::P::EscapeHTML, if automatic_esaping is
>> enabled, will follow that reference, trampling all over the values of
>> the settings.
>>
>> That, needless to say, is Not Good, and is the cause of the problem.
>>
>> I think the proper fix is for me to change Dancer::Template::Abstract
>> to copy the settings rather than storing a reference - e.g.:
>>
>>     $tokens->{settings} = Clone::clone(Dancer::Config->settings);
>
> I've implemented that in a pull request:
>
> https://github.com/sukria/Dancer/pull/775
>
> Please feel free to test that this fixes the issue for you (although I
> realise as the problem only manifested once the existing connection
> went away, it'll be somewhat tricky to reproduce, unless you can cause
> the database connection to drop via whatever means you choose).
>
> I've tested the fix with a simple test case which demonstrated the
> previously described problem, and verified that the changes in that PR
> do indeed fix it.
>
>
> --
> David Precious ("bigpresh") <davidp at preshweb.co.uk>
> http://www.preshweb.co.uk/     www.preshweb.co.uk/twitter
> www.preshweb.co.uk/linkedin    www.preshweb.co.uk/facebook
> www.preshweb.co.uk/cpan        www.preshweb.co.uk/github
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users