Re: [Catalyst] Postgresql database with non default -public- schema

2010-10-21 Thread Benjamin Martin

On 20/10/10 18:40, Hetényi Csaba wrote:

The automatic schema generation is a very convenient feature -especially
in developing phase, when table structures often change.


I hear you!... I have the exact same issue.

So far writing my own script that harnesses the power of 
DBIX::Class::Schema::Loader to run over each schema in my DB seems to be 
working out well... althou, due to some horrific column naming my dbic 
objects have a some ugly accessor names... I feel I 'might' start 
manually managing my ::Result:: files :(


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Running system commands under FastCGI with IPC::Cmd / IPC::Run

2010-10-21 Thread Ian Sillitoe
I have a Catalyst model that runs a system command as part of a search
facility. The system call only takes a fraction of a second so is processed
inline and this all works fine when tested outside of Catalyst and when
called under the Catalyst standalone server. However, when I deploy it to my
FastCGI environment I have problems - everything seems to work fine apart
from the results of the system call.

The system call is (give or take):

IPC::Cmd::run(
command = [qw/ blastall -d sequences.db -i input.fa -o
output.results /],
verbose = 0,
timeout = 10,
);

When run under the test server the file 'output.results' contains the
results of the search:

gi|5524211|gb|AAD441661|pdb|3cx5C00 45.26   285 154
1   1   283 91  375 4e-73267
gi|5524211|gb|AAD441661|pdb|2e74A00 33.33   99  65
1   21  118 117 215 9e-16   77.0
gi|5524211|gb|AAD441661|pdb|2ih2A01 34.78   23  15
0   115 137 85  107 4.0 25.0
...

When the same application is being run under FastCGI the file is created but
is empty.

The system call was originally being wrapped with IPC::Cmd (via
MooseX::Role::Cmd). I checked what happened when I explicitly used IPC::Run

my ($in, $out, $err);
my $success = IPC::Run::run [qw/ blastall -d sequences.db -i input.fa -o
output.results /], \$in, \$out, \$err, IPC::Run::timeout( 10 );

This works under the test server, but throws the following error under
FastCGI:

Can't locate object method FILENO via package FCGI::Stream at
/home/ian/perl5/lib/perl5/IPC/Run.pm line 1115.


If I bypass IPC::* and run the system command with backticks then it seems
to work fine under both the test server and FastCGI. However the system call
is happening a long way away from Catalyst - I don't really want to hard
code this with backticks just to get it working under FastCGI.

There seems to be a few different things going on here - I'm not sure
exactly where the problem lies or what might be a red herring - would be
grateful if anyone can help point me in the right direction.

Cheers,

Ian




Running FastCGI server on my desktop on port 3001:

  script/my_app_fastcgi.pl -l bsmlx53:3001 -n 3 -p my-app.pid -d

Forwarding requests there from external facing server with the following
config:

  VirtualHost *:80
ServerName  test.foo.com
DocumentRoot/home/ian/My-App/trunk/
ErrorLoglogs/test.foo.com-error_log

FastCgiExternalServer   /tmp/my-app.fcgi -host bsmlx53:3001

Alias   /static /home/ian/My-App/trunk/root/static
Alias   /   /tmp/my-app.fcgi/
  /VirtualHost

Modules:

  Catalyst::Runtime (5.80029)
  IPC::Run (0.89)
  FCGI (0.67)
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Running system commands under FastCGI with IPC::Cmd / IPC::Run

2010-10-21 Thread Stuart Watt
You may want to check your version of FCGI. There are previous reports 
of related issues, which seem to be an interaction between IPC::*  
modules expectations of standard input/output/error, and FCGI, which 
fakes them. See 
http://www.mail-archive.com/po...@openbsd.org/msg16948.html for an 
example. In my FCGI, the FILENO method is present, but this appears to 
have been added in version 0.67_01 on 20 Dec 2009 - this is pretty 
recent and your Perl may not include it.


--S

Stuart Watt
ARM Product Developer
Information Balance


On 10/21/2010 2:43 PM, Ian Sillitoe wrote:


I have a Catalyst model that runs a system command as part of a search 
facility. The system call only takes a fraction of a second so is 
processed inline and this all works fine when tested outside of 
Catalyst and when called under the Catalyst standalone server. 
However, when I deploy it to my FastCGI environment I have problems - 
everything seems to work fine apart from the results of the system call.


The system call is (give or take):

IPC::Cmd::run(
command = [qw/ blastall -d sequences.db -i input.fa -o 
output.results /],

verbose = 0,
timeout = 10,
);

When run under the test server the file 'output.results' contains the 
results of the search:


gi|5524211|gb|AAD441661|pdb|3cx5C00 45.26   285 
154 1   1   283 91  375 4e-73267
gi|5524211|gb|AAD441661|pdb|2e74A00 33.33   99  
65  1   21  118 117 215 9e-16   77.0
gi|5524211|gb|AAD441661|pdb|2ih2A01 34.78   23  
15  0   115 137 85  107 4.0 25.0

...

When the same application is being run under FastCGI the file is 
created but is empty.


The system call was originally being wrapped with IPC::Cmd (via 
MooseX::Role::Cmd). I checked what happened when I explicitly used 
IPC::Run


my ($in, $out, $err);
my $success = IPC::Run::run [qw/ blastall -d sequences.db -i 
input.fa -o output.results /], \$in, \$out, \$err, IPC::Run::timeout( 
10 );


This works under the test server, but throws the following error under 
FastCGI:


|Can't locate object method FILENO via package FCGI::Stream at 
/home/ian/perl5/lib/perl5/IPC/Run.pm line 1115.

|

If I bypass IPC::* and run the system command with backticks then it 
seems to work fine under both the test server and FastCGI. However the 
system call is happening a long way away from Catalyst - I don't 
really want to hard code this with backticks just to get it working 
under FastCGI.


There seems to be a few different things going on here - I'm not sure 
exactly where the problem lies or what might be a red herring - would 
be grateful if anyone can help point me in the right direction.


Cheers,

Ian




Running FastCGI server on my desktop on port 3001:

  script/my_app_fastcgi.pl http://my_app_fastcgi.pl -l bsmlx53:3001 
-n 3 -p my-app.pid -d


Forwarding requests there from external facing server with the 
following config:


VirtualHost *:80
ServerName test.foo.com http://test.foo.com
DocumentRoot/home/ian/My-App/trunk/
ErrorLoglogs/test.foo.com-error_log

FastCgiExternalServer   /tmp/my-app.fcgi -host bsmlx53:3001

Alias   /static /home/ian/My-App/trunk/root/static
Alias   /   /tmp/my-app.fcgi/
/VirtualHost

Modules:

  Catalyst::Runtime (5.80029)
  IPC::Run (0.89)
  FCGI (0.67)



--
This message was scanned by ESVA and is believed to be clean.
Click here to report this message as spam. 
http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=7751128072.AE451



___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Running system commands under FastCGI with IPC::Cmd / IPC::Run

2010-10-21 Thread heidi brandenburg
I've run into this problem with FCGI too. Our solution at the time, since the 
fileno call was in an internal API, was to skip it when STDOUT was tied. 
Getting an updated FCGI instead sounds like a happier thing.

I notice this in current FCGI comments:

# Some things (e.g. IPC::Run) use fileno to determine if a filehandle is open,
# so we return a defined, but meaningless value. (-1 being the error return
# value from the syscall in c, meaning it can never be a valid fd no)
# Probably a better alternative would be to return the fcgi stream fd.
sub FILENO { -1 }


On Oct 21, 2010, at 12:29 PM, Stuart Watt wrote:

 You may want to check your version of FCGI. There are previous reports of 
 related issues, which seem to be an interaction between IPC::*  modules 
 expectations of standard input/output/error, and FCGI, which fakes them. See 
 http://www.mail-archive.com/po...@openbsd.org/msg16948.html for an example. 
 In my FCGI, the FILENO method is present, but this appears to have been added 
 in version 0.67_01 on 20 Dec 2009 - this is pretty recent and your Perl may 
 not include it.
 
 --S
 
 Stuart Watt
 ARM Product Developer
 Information Balance
 
 
 On 10/21/2010 2:43 PM, Ian Sillitoe wrote:
 
 I have a Catalyst model that runs a system command as part of a search 
 facility. The system call only takes a fraction of a second so is processed 
 inline and this all works fine when tested outside of Catalyst and when 
 called under the Catalyst standalone server. However, when I deploy it to my 
 FastCGI environment I have problems - everything seems to work fine apart 
 from the results of the system call.
 
 The system call is (give or take):
 
 IPC::Cmd::run(
 command = [qw/ blastall -d sequences.db -i input.fa -o 
 output.results /], 
 verbose = 0,
 timeout = 10,
 );
 
 When run under the test server the file 'output.results' contains the 
 results of the search:
 
 gi|5524211|gb|AAD441661|pdb|3cx5C00 45.26   285 154 1
1   283 91  375 4e-73267
 gi|5524211|gb|AAD441661|pdb|2e74A00 33.33   99  65  1
21  118 117 215 9e-16   77.0
 gi|5524211|gb|AAD441661|pdb|2ih2A01 34.78   23  15  0
115 137 85  107 4.0 25.0
 ...
 
 When the same application is being run under FastCGI the file is created but 
 is empty.
 
 The system call was originally being wrapped with IPC::Cmd (via 
 MooseX::Role::Cmd). I checked what happened when I explicitly used IPC::Run
 
 my ($in, $out, $err);
 my $success = IPC::Run::run [qw/ blastall -d sequences.db -i input.fa -o 
 output.results /], \$in, \$out, \$err, IPC::Run::timeout( 10 );
 
 This works under the test server, but throws the following error under 
 FastCGI:
 
 Can't locate object method FILENO via package FCGI::Stream at 
 /home/ian/perl5/lib/perl5/IPC/Run.pm line 1115.
 
 
 
 If I bypass IPC::* and run the system command with backticks then it seems 
 to work fine under both the test server and FastCGI. However the system call 
 is happening a long way away from Catalyst - I don't really want to hard 
 code this with backticks just to get it working under FastCGI.
 
 There seems to be a few different things going on here - I'm not sure 
 exactly where the problem lies or what might be a red herring - would be 
 grateful if anyone can help point me in the right direction.
 
 Cheers,
 
 Ian
 
 
 
 
 Running FastCGI server on my desktop on port 3001:
 
   script/my_app_fastcgi.pl -l bsmlx53:3001 -n 3 -p my-app.pid -d
 
 Forwarding requests there from external facing server with the following 
 config:
 
   VirtualHost *:80
 ServerName  test.foo.com
 DocumentRoot/home/ian/My-App/trunk/
 ErrorLoglogs/test.foo.com-error_log
 
 FastCgiExternalServer   /tmp/my-app.fcgi -host bsmlx53:3001  
 
 Alias   /static /home/ian/My-App/trunk/root/static
 Alias   /   /tmp/my-app.fcgi/
   /VirtualHost
 
 Modules:
 
   Catalyst::Runtime (5.80029)
   IPC::Run (0.89)
   FCGI (0.67)
 
 
 
 -- 
 This message was scanned by ESVA and is believed to be clean. 
 Click here to report this message as spam.
 
 ___
 List: 
 Catalyst@lists.scsys.co.uk
 
 Listinfo: 
 http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 
 Searchable archive: 
 http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 
 Dev site: 
 http://dev.catalyst.perl.org/
 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: 

Re: [Catalyst] Running system commands under FastCGI with IPC::Cmd / IPC::Run

2010-10-21 Thread Peter Karman
heidi brandenburg wrote on 10/21/2010 03:02 PM:
 I've run into this problem with FCGI too. Our solution at the time, since the 
 fileno call was in an internal API, was to skip it when STDOUT was tied. 
 Getting an updated FCGI instead sounds like a happier thing.
 
 I notice this in current FCGI comments:
 
 # Some things (e.g. IPC::Run) use fileno to determine if a filehandle is open,
 # so we return a defined, but meaningless value. (-1 being the error return
 # value from the syscall in c, meaning it can never be a valid fd no)
 # Probably a better alternative would be to return the fcgi stream fd.
 sub FILENO { -1 }
 
 

In addition, you may want to look at SVN::Class, which does some fileno
hackery for this same reason.

http://cpansearch.perl.org/src/KARMAN/SVN-Class-0.16/lib/SVN/Class.pm

-- 
Peter Karman  .  http://peknet.com/  .  pe...@peknet.com

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Running system commands under FastCGI with IPC::Cmd / IPC::Run

2010-10-21 Thread Toby Corkindale
On 22 October 2010 05:43, Ian Sillitoe i...@sillit.com wrote:
 I have a Catalyst model that runs a system command as part of a search
 facility. The system call only takes a fraction of a second so is processed
 inline and this all works fine when tested outside of Catalyst and when
 called under the Catalyst standalone server. However, when I deploy it to my
 FastCGI environment I have problems - everything seems to work fine apart
 from the results of the system call.

 The system call is (give or take):

     IPC::Cmd::run(
     command = [qw/ blastall -d sequences.db -i input.fa -o
 output.results /],
     verbose = 0,
     timeout = 10,
     );

I recall that IPC::Run certainly has known-issues when used under
FastCGI, and I'm guessing they extend to IPC::Cmd too.

Have a look at IPC::Run::SafeHandles which I think got around it.

Toby

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/