On 18 June 2011 12:34, Rob Kinyon rob.kin...@gmail.com wrote:
Uprgrading perl versions can require OS upgrades if your sysadmins say so.
It can also require significant testing burden because code optimized to 5.8
doesn't run cleanly under 5.10 or above. And then there is the question of
On 14 June 2011 22:40, Peter Rabbitson rabbit+d...@rabbit.us wrote:
Toby Corkindale wrote:
On 9 June 2011 17:51, Jorge Gonzalez jorge.gonza...@daikon.es wrote:
BTW, thanks for resurrecting a 3 month old thread :-) I had not checked
the EOL status of 5.8 and 5.10. And then again: RHEL 6 is
Uprgrading perl versions can require OS upgrades if your sysadmins say so. It
can also require significant testing burden because code optimized to 5.8
doesn't run cleanly under 5.10 or above. And then there is the question of
modperl 1 vs modperl 2 vs fastcgi and module deps. I have seen 12
On 9 June 2011 17:51, Jorge Gonzalez jorge.gonza...@daikon.es wrote:
BTW, thanks for resurrecting a 3 month old thread :-) I had not checked the
EOL status of 5.8 and 5.10. And then again: RHEL 6 is based on 5.10, which is
also EOL'ed...?
Yes, only the current and prior-to-current versions
Toby Corkindale wrote:
On 9 June 2011 17:51, Jorge Gonzalez jorge.gonza...@daikon.es wrote:
BTW, thanks for resurrecting a 3 month old thread :-) I had not checked the EOL
status of 5.8 and 5.10. And then again: RHEL 6 is based on 5.10, which is also
EOL'ed...?
Yes, only the current and
My dev environment (and so, my production environment) is based on
Centos5, which is 5.8.8 based and I can't upgrade the system's perl
without assuming too many risks (for production, that is).
But since all my Perl production apps ship complete with their own perl
installation (local::lib),
Well.
I installed 5.14.0 with perlbrew, besides the system's perl and fully
reinstalled everything for my app. I restored the 125 tables remote
Oracle schema to the schema Result directory, so my app now loads some
150 DBIx result classes on startup, and uses some of them.
Everything works
On 1 March 2011 01:39, Jorge Gonzalez jorge.gonza...@daikon.es wrote:
I'm developing an app with Catalyst 5.80024, on perl 5.8.8, 32 bits;
DBIx::Class models.
[snip]
Perl 5.8.x has been beyond end-of-life for quite a while, as has
5.10.x more recently. The 5.8 stream is almost ten years old,
Thanks, I'll try :-)
Regards
J.
Jorge González Villalonga
Director Técnico
DAIKON Integración y
Desarrollo S.L.
Telf: (+34) 91 188 08 28
Fax: (+34) 91 632 65 42
www.daikon.es
El 01/03/11 08:27, Peter Rabbitson escribió:
Attached is a test
Jorge Gonzalez wrote:
Hi,
I'm developing an app with Catalyst 5.80024, on perl 5.8.8, 32 bits;
DBIx::Class models.
Also you didn't mention the most important factor - which version of
DBIx::Class itself were you using? There are currently no known slowdowns
while working with multiple
Oooops, my fault:
DBIx::Class: version 0.08123.
Multiple tables - OK, but _lots_ of tables? I tend to associate
"multiple" with something in the couples, perhaps tens. But for 100
I tend to speak about "lots" :-)
Regards
J.
Jorge González Villalonga
Director Técnico
Yes and yes. :-)
Jorge González Villalonga
Director Técnico
DAIKON Integración y
Desarrollo S.L.
Telf: (+34) 91 188 08 28
Fax: (+34) 91 632 65 42
www.daikon.es
El 28/02/11 16:34, Peter Edwards escribió:
On 28 February 2011 15:27, Jorge
Jorge Gonzalez wrote:
Hi,
I'm developing an app with Catalyst 5.80024, on perl 5.8.8, 32 bits;
DBIx::Class models.
I experienced very bad performance: index pages loading in 30 seconds or
more, and Catalyst reporting that the request took 40s and the like.
Completely unbearable.
After
13 matches
Mail list logo
