Koha::Schema::Result::*

[MagnusEnger]

Hi!

Thanks for creating koha-gitify - it makes Koha even more fun! :-)

I think I have found a problem, though, while doing development on a gitified setup. This is related to DBIC and the stuff in Koha::Schema::Result::*

Specifically, I have:

• Added some new columns to the "borrowers" table ("syncstatus", amongst others)
• Re-generated the DBIC Class files with misc/devel/update_dbix_class_files.pl
• Written a command line script that reads some data from the new columns
• When I run the script, I get: Can't locate object method "syncstatus" via package "Koha::Schema::Result::Borrower" at misc/cronjobs/nl-sync.pl line 85.
• When I look in Koha/Schema/Result/Borrower.pm the new columns are there, and everything looks good, but I keep getting the error (so it looks like misc/devel/update_dbix_class_files.pl is doing its job)
• When I do this the error goes away: sudo cp Koha/Schema/Result/Borrower.pm /usr/share/koha/lib/Koha/Schema/Result/Borrower.pm

So it looks like DBIC is using the installed files for Koha::Schema::Result::*, instead of the ones in my cloned repo. I have no idea what might be causing this, or even if it is a problem with koha-gitify, but this seemed like the right place to start...

Best regards, Magnus

[chrisosaurus]

Hi Magnus

I don't have a running koha to test on, but this to me sounds like you have a PERL5LIB setting that is not pointing to your clone, many of the scripts have a hard-coded PERL5LIB setting (check debian/scripts/* in the koha git repo).

Koha-gitify is not able to change these perl5lib settings because those scripts are currently shared across all koha instances on an env (where each instance may have a different code path).

I have been considering writing a koha-env script that constructs a PERL5LIB path from the configs that koha-gitify modifies, but at this point such a thing does not exist.

If you are happy with all your koha instances on this machine running from the same code you should be able to change the PERL5LIB lines in each of the scripts manually to point to your git checkout.

[MagnusEnger]

You are very probably right. The code for koha-shell includes this:

# Now we're set up, build the 'su' command
my @su_args;
push @su_args, '/bin/su';
push @su_args, '--preserve-environment' if $opts{'preserve-environment'};
push @su_args, '--login' if $opts{login};
push @su_args, '--command',
    "env "
  . "KOHA_CONF=/etc/koha/sites/$instance/koha-conf.xml "
  . "PERL5LIB=/usr/share/koha/lib $shell"
  . ( $opts{command} ? " -c '$opts{command}'" : '' );
push @su_args, "$instance-koha";

And after I discover the -v switch to that script I can see:

$ sudo koha-shell -c "echo \$PERL5LIB" -v kohadev
Command: '/bin/su' '--command' 'env KOHA_CONF=/etc/koha/sites/kohadev/koha-conf.xml PERL5LIB=/usr/share/koha/lib /bin/bash -c 'echo $PERL5LIB'' 'kohadev-koha'
/usr/share/koha/lib

But I am pretty sure changes to modules in C4 and Koha have worked for me, and that only Koha::Schema::Result::* were problematic. I'll see if I can investigate some more...

[MagnusEnger]

Sorry for not getting back to this earlier! Including PERL5LIB on the command line fixes things, like you suggested:

$ sudo koha-shell -c "PERL5LIB=/home/me/kohaclone prove t/MyTest.t" mydevinstall

Not sure there is anything to fix then, but perhaps it could be documented somewhere?

[chrisosaurus]

This should definitely make it into a document somewhere, maybe a FAQ or similar.