I have a Dancer app that is working. I am using DBIC for the database.
I want to add some tables to the database, and so I created new files for those. However, now when I restart the app, I get the following errors
Error while loading ././bin/app.pl: Could not load schema_class MyApp::Schema at /usr/local/share/perl/5.14.2/Dancer/Plugin/DBIC.pm line 42.
Compilation failed in require at ././bin/app.pl line 5.
BEGIN failed--compilation aborted at ././bin/app.pl line 5.
When I remove the new files, everything works fine.
Here is my Schema.pm file
package MyApp::Schema;
# Created by DBIx::Class::Schema::Loader
# DO NOT MODIFY THE FIRST PART OF THIS FILE
use strict;
use warnings;
use base 'DBIx::Class::Schema';
__PACKAGE__->load_namespaces;
1;
Where can I get more information about the error and what I did wrong?
Since you are using __PACKAGE__->load_namespaces, all new classes will loaded, which explains why the simple existence of the new class files cause an error. If there is a syntax error in your new class files, then loading the schema will die.
You can use perl -c on the new class files to ensure they will compile and get a better idea of the problem if they do not.
Related
I was trying to install Carton into local directory for my project and got error:
--> Working on Test::Deep
Fetching...
...
t/isa.t ..................... Can't locate Mojo/Base.pm in #INC (you may need to install the Mojo::Base module) (#INC contains: CODE(0x557913d006d0) t/lib /home/kes/.cpanm/work/1626520042.29670/Test-Deep-1.130/blib/lib /home/kes/.cpanm/work/1626520042.29670/Test-Deep-1.130/blib/arch /home/kes/work/projects/tucha/monkeyman/local/lib/perl5/x86_64-linux /home/kes/work/projects/tucha/monkeyman/local/lib/perl5 /home/kes/work/projects/tucha/monkeyman/lib /home/kes/perl5/perlbrew/perls/perl-5.35.1/lib/site_perl/5.35.1/x86_64-linux /home/kes/perl5/perlbrew/perls/perl-5.35.1/lib/site_perl/5.35.1 /home/kes/perl5/perlbrew/perls/perl-5.35.1/lib/5.35.1/x86_64-linux /home/kes/perl5/perlbrew/perls/perl-5.35.1/lib/5.35.1 CODE(0x557913d00670) .) at /home/kes/work/projects/tucha/monkeyman/lib/A.pm line 2.
BEGIN failed--compilation aborted at /home/kes/work/projects/tucha/monkeyman/lib/A.pm line 2.
Compilation failed in require at /home/kes/perl5/perlbrew/perls/perl-5.35.1/lib/5.35.1/base.pm line 138.
...propagated at /home/kes/perl5/perlbrew/perls/perl-5.35.1/lib/5.35.1/base.pm line 160.
BEGIN failed--compilation aborted at t/isa.t line 133.
This error occur because my application has A module, but t/isa.t defines already its own package A which is loaded into memory already.
# Test::Deep:t/isa.t:120
package A;
use Test::Deep;
#A::ISA = qw( Test::Deep );
{
::ok(A->isa("Test::Deep"), "U::isa says yes");
::ok(! A->isa("Test"), "U::isa says yes");
}
{
package C;
use base 'A'; # <<<< this cause error
}
But why use base 'A' tries to reload package A from disk while package A is already loaded into memory?
perl -v
5.35.1
You are experiencing the difference between packages and modules. A package is a namespace. A module is a file. It's easy to confuse them because by convention, the definition of the Foo::Bar::Baz namespace will be in file Foo/Bar/Baz.pm.
When you write:
use Foo::Bar::Baz;
Perl interprets that as two instructions:
Load the file Foo/Bar/Baz.pm if it's not already loaded.
Call the method import on the Foo::Bar::Baz namespace.
(And use base 'Foo::Bar::Baz' does similar, except instead of #2, it does some funky stuff with inheritance.)
So in your case, when you do use base 'A', Perl will do #1 unless file A.pm is already loaded. Yes, you've already defined some stuff in the A namespace, but that doesn't matter.
A few different solutions for you.
Trick Perl into thinking A.pm is already loaded
Adding this line somewhere before use base 'A' will trick Perl into thinking A.pm has already been loaded.
BEGIN { $INC{'A.pm'} = __FILE__ };
use parent
Do this instead of use base 'A':
use parent '-norequire', 'A';
parent is the more modern version of base and has a -norequire option to skip step #1.
use neither base nor parent
All those modules are doing for you are setting the #ISA variable for you. You can do that yourself.
{
package C;
our #ISA = 'A';
}
I have code (some lines are removed):
package MaitreD::Command::bank_statement;
use Mojo::Base 'Mojolicious::Command';
sub run {
...
my $payments = read_file( $file ); # line 58
...
}
use XBase; # line 174
sub read_file {
...
}
1;
I run my application. And then do two http requests to this app. Controller runs this command as:
$c->app->commands->run( bank_statement => $upload );
I get next error (this one is expected):
Can't locate XBase.pm in #INC (you may need to install the XBase module) (#INC contains: /opt/monkeyman/lib /opt/monkeyman/local/lib/perl5/x86_64-linux /opt/monkeyman/local/lib/perl5 /opt/monkeyman/lib /opt/monkeyman/local/lib/perl5/5.24.1/x86_64-linux /opt/monkeyman/local/lib/perl5/5.24.1 /opt/monkeyman/local/lib/perl5/x86_64-linux /opt/monkeyman/local/lib/perl5 /opt/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.1/x86_64-linux /opt/perlbrew/perls/perl-5.24.1/lib/site_perl/5.24.1 /opt/perlbrew/perls/perl-5.24.1/lib/5.24.1/x86_64-linux /opt/perlbrew/perls/perl-5.24.1/lib/5.24.1 .) at /opt/monkeyman/lib/MaitreD/Command/bank_statement.pm line 174.
BEGIN failed--compilation aborted at /opt/monkeyman/lib/MaitreD/Command/bank_statement.pm line 174.
Compilation failed in require at (eval 2620) line 1.
But when I did second request I got different error:
Undefined subroutine &MaitreD::Command::bank_statement::read_file called at /opt/monkeyman/lib/MaitreD/Command/bank_statement.pm line 58.
How MaitreD::Command::bank_statement::run could be run from controller if module MaitreD::Command::bank_statement compilation failed?
If understand correct the module MaitreD::Command::bank_statement was compiled partially to 174 line. So next http request to app can call MaitreD::Command::bank_statement::run and when 58 line is reached I get Undefined subroutine &M::C::b::read_file called because nothing is compiled after 174 line.
How to prevent partial compilation?
I want if there are some errors occur then nothing from MaitreD::Command::bank_statement should be available
It seems you should be focusing on ensuring use XBase actually succeeds, beause presumably it's there for a reason and it's needed for the rest of the program to work.
Why does it fail? Fix that first and the partial compilation isn't a problem.
In this case, why can't perl find the module?
Is it possible the Command::bank_statement class isn't used directly, but only when it's being run, so maybe the current working directory changed between the program start and the time $c->app->commands->run( bank_statement => $upload ); was called?
If that's the case, try loading the command class earlier. e.g. add this to the Mojo application class (probably something like lib/MaitreD.pm:
use MaitreD::Command::bank_statement;
I am attempting to write a check in my Cake build script to pull in a file from BuildParameters and check if the file contents are empty -- if contents are empty, throw an exception and quit the build.
I am attempting to use FileReadText from the FileHelpers namespace but for some reason I cannot get my build to recognize the file command. I am following the syntax and documentation found here: https://cakebuild.net/api/Cake.FileHelpers/FileHelperAliases/97F5679A
Here is the code I am trying in build.cake:
var fileReadText= FileReadText(Parameters.TestParameters.TestListFP);
var fileText= fileReadText.ThrowIfNullOrEmpty(nameof(fileReadText));
The argument Parameters.TestParameters.TestListFP is set in my Parameters.cake file as such:
TestListFP = context.File("C:\Some\Path\some_file_name.txt");
Using the above code, I see this error:
error CS0103: The name 'FileReadText' does not exist in the current
context
Note that I do not have a ICakeContext in build.cake, just BuildParameters.
I tried to resolve the issue by adding using Cake.FileHelpers; at the top of my build.cake file, but then I see this error:
The type or namespace name 'FileHelpers' does not exist in the namespace 'Cake' (are you missing an assembly reference?)
The script works fine without my FileReadText code, so I know TestListFP is actually a valid file.
I think I am inherently misunderstanding how to use FileHelpers and FileReadText and I could not find any examples of usage in documentation or anywhere else. If anyone has guidance on how to use this method, or a better way to accomplish what I am trying to do, I would appreciate the help.
Have you added the #addin pre-processor directive, as mentioned here:
https://github.com/cake-contrib/Cake.FileHelpers/#cakefilehelpers
You can easily reference Cake.FileHelpers directly in your build script via a cake addin:
#addin "Cake.FileHelpers"
The module it's failing to install is JSON::XS. Really it's failing to install anything
that has the following code:
BEGIN { plan tests => 5 };
From the build.log:
syntax error at t/04_dwiw_encode.t line 13, near "plan tests"
The offending line:
13 BEGIN { plan tests => 5 }
I read that there's a problem with Test.pm but there are quite a few modules
using it and furthermore this just started happening recently.
I just tried reinstalling perlbrew and also tried updating outdated modules
but I keep getting the same failures.
Any one have an idea what might have caused this and how to fix it?
I suspect you either have an older-than-expected version of the Test module, or you created your own module named Test.pm and it's getting picked up instead of the expected module.
You can address the first issue by upgrading Test.
cpan Test
You should address the second issue by renaming your Test.pm to something else, but you might also be able to address it by changing directory and temporarily clearing the PERL5LIB env var.
pushd / ; PERL5LIB= cpan JSON::XS ; popd
I'm having somewhat weird problem with DBD::Informix. If I run a simple script like that:
use DBI;
my $dbh = DBI->connect_cached('dbi:Informix:database', '', '');
my $sth = $dbh->prepare('select foo from bar');
...
It works all right. But if I try to do exactly the same from a test script it fails with the following message:
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
The only difference I see is that test script is quite heavy on module usage; it is based on Test::More and loads a lot of submodules that are to be tested.
Turning on DBI trace does not provide anything useful (for me, at least). Simple script runs along just fine:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9685 pi 0) at test_ifx.pl line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9685 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0x1c8070)
!! warn: 0 CLEARED by call to connect method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms#cms_ol' - no user info
-->> DBD::Informix::dbd_ix_db_check_for_autocommit()
... and the only difference in trace of the problematic script I see is that it just fails:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9687 pi 0) at 22_report.t line 5 via 22_report.t line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect_cached(dbi:Informix:cms, , ****)
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9687 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0xb619bc)
!! warn: 0 CLEARED by call to connect_cached method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms' - no user info
***ERROR***
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
<<-- dbd_ix_db_connect (**ERROR-1**)
<<-- DBD::Informix::dbd_ix_db_connect()
I'm running custom Perl 5.8.9 build in Solaris 9, with latest DBI and DBD::Informix versions, against Informix IDS 9.40UC.
Update: If I try to be a smartass and put a block like that at the top of the heavy test script:
use DBI;
BEGIN { my $dbh = DBI->connect_cached( ... ); print "Connected!\n" if $dbh; }
... it prints like this:
Connected!
Out of memory!
Callback called exit.
END failed--call queue aborted at t/22_report.t line 20.
Callback called exit at t/22_report.t line 20.
BEGIN failed--compilation aborted at t/22_report.t line 24.
My guess is that DBD::Informix conflicts with some of the modules loaded after the connection is made. But which one? That's the question...
Another update: It appears that the above trick does something unwieldy. I tried to load all the modules explicitly by replacing 'use Module' with 'require Module; Module->import'. Pure Perl modules are OK but whenever XS module using XSLoader appears, Perl goes boom with friendly 'Out of memory' message. And if I move Informix connection below module initialization, it works all right - except DBD::Informix fails with the same -25588 error. Boomer. I'm at loss. :(
Another another update: I tried to run the same script with standard Perl 5.6.1 shipped with Solaris 9, using DBI 1.601 (the latest that would compile with Perl 5.6) and DBD::Informix 2011.0612. Same thing, so it's not custom Perl giving me trouble.
I can also add that the test module in question was prototyped using DBD::SQLite and fully works. It is the final test with DBD::Informix that is failing... As usual. :/
Workaround: following e-mail discussion with Jonathan, a workaround was found: addition of streams-based 'onipcstr' connection to Informix server allowed DBD::Informix to connect. Apparently, some XS modules interfere with default shmem-based connection method, although the culprit is unknown at the moment.
Further discussion
Custom-built Perl is, in my experience, easier than the system Perl. I never modify the system's Perl installation (I don't want to break it) so I always build my own.
You appear to have:
Solaris 9 (SPARC?)
Perl 5.8.9
DBI 1.616
DBD::Informix 2011.0612
ESQL/C (CSDK) 2.81
Informix Dynamic Server 9.40
We don't have the detailed sub-version of ESQL/C and IDS (2.81.UC2, 9.40.UC5, or whatever). There's a hint that you are using a 32-bit version of IDS, so probably everything is 32-bit. You are probably aware that 9.40 is no longer supported by IBM (and, indeed, its successor version 10.00 is also out of support). However, superficially, none of that should matter very much. The failing t91lvarchar.t is not a big issue.
Can you run the connect in working and non-working modes with DBI_TRACE=9 set in the environment.
If the trace for the connect operation is too voluminous to go into an update to the question, we'd better take this off-line to the DBD::Informix support channels (that's me, but by email).
The 'ISAM' error of 22 (Invalid argument) is puzzling. I'm curious about what is in your sqlhosts file for this server - the entry for cms_ol specifically. I'm not sure it will reveal anything, not least because you say the sample ESQL/C below (in the 'First hypothesis' section) works OK, and sometimes the Perl connects and sometimes it does not.
I wonder if there is a name conflict somewhere between functions in the shared libraries? That sort of thing will be hell to track.
First hypothesis
Further information received shows that this was not the crucial distinction.
The difference appears to be:
Works: CONNECT TO 'cms#cms_ol' - no user info
Fails: CONNECT TO 'cms' - no user info
The tricky part to explain is why the second fails, especially as the error goes on to mention cms_ol.
The workaround is to specify the server name in the connect string:
DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
DBI->connect_cached(dbi:Informix:cms, , ****)
The underlying problem is more likely at the ESQL/C level than anything to do with other Perl modules. That is, if you compiled and executed this ESQL/C program, it would fail on cms and work on cms#cms_ol:
int main(int argc, char **argv)
{
$ char *dbs = "cms";
if (argc > 1)
dbs = argv[1];
$ whenever error stop;
$ connect to :dbs;
return 0;
}
You could run it without an explicit database name (or with an explicit 'cms'), and I would expect it to fail. You could run it with 'cms#cms_ol' and I would expect it to pass. The program will say nothing if it passes; it will be obvious when it fails (though the messages will not be beautiful).
There is an outside chance it is something to do with connect_cached; that is a service provided by the DBI module and not by the DBD::Informix module. On the whole though, it is more likely something happening at the ESQL/C level.