bug: foreign keys use wrong table name, part 2

[mario-minati]

There is an other line in Yancy::Backend::Dbic which needs fixing, acording to #84.

https://github.com/preaction/Yancy/blob/master/lib/Yancy/Backend/Dbic.pm#L350 needs to be fixed to my $self_table = $source->source_name;.

[preaction]

Okay, thanks, that seems simple enough. Not being as experienced in DBIC, how could I trigger that issue? Do I create a source with a name that's entirely different from the table name? I'd like to have a regression test for this.

[mario-minati]

Our result classes have nothing special:

package Glue::DB::Schema::Core::Result::Project;

# ABSTRACT: Result class for project

use strict;
use warnings;
use utf8;
use base qw(DBIx::Class);

our $VERSION = 27;

__PACKAGE__->load_components( qw/PK::Auto Core/ );
__PACKAGE__->table( 'project' );
__PACKAGE__->add_columns(
    id => {
        data_type          => 'INT',
        is_auto_increment  => 1,
        is_numeric         => 1,
        retrieve_on_insert => 1,
    },
    name => {
        data_type          => 'VARCHAR',
        size               => 255,
    },
    abbreviation => {
        data_type          => 'VARCHAR',
        size               => 15,
    },
    description => {
        data_type          => 'MEDIUMTEXT',
        is_nullable        => 1,
    },
    projectnumber => {
        data_type          => 'VARCHAR',
        size               => 15,
    },
);
__PACKAGE__->set_primary_key( qw/ id / );

__PACKAGE__->has_many(project_costcenter => 'Glue::DB::Schema::Core::Result::ProjectCostcenter',
             { 'foreign.project_id' => 'self.id' });

1;

package Glue::DB::Schema::Core::Result::ProjectCostcenter;

# ABSTRACT: Result class for project_costcenter

use strict;
use warnings;
use utf8;
use base qw(DBIx::Class);

our $VERSION = 27;

__PACKAGE__->load_components( qw/PK::Auto Core ColumnDefault/ );
__PACKAGE__->table( 'project_costcenter' );
__PACKAGE__->add_columns(
    id => {
        data_type          => 'INT',
        is_auto_increment  => 1,
        is_numeric         => 1,
        retrieve_on_insert => 1,
    },
    name => {
        data_type          => 'VARCHAR',
        size               => 255,
    },
    description => {
        data_type          => 'MEDIUMTEXT',
        is_nullable        => 1,
    },
    is_blocked => {
        data_type          => 'TINYINT',
        size               => 1,
        default_value      => '0',
    },
    project_id => {
        data_type          => 'INT',
        is_numeric         => 1,
        is_foreign_key     => 1,
    },

);
__PACKAGE__->set_primary_key( qw/ id / );

__PACKAGE__->has_many(project_costcenter_abbreviation => 'Glue::DB::Schema::Core::Result::ProjectCostcenterAbbreviation',
             { 'foreign.project_costcenter_id' => 'self.id' });

__PACKAGE__->has_many(timerecording => 'Glue::DB::Schema::Core::Result::Timerecording',
             { 'foreign.project_costcenter_id' => 'self.id' });

__PACKAGE__->belongs_to(project => 'Glue::DB::Schema::Core::Result::Project',
             { 'foreign.id' => 'self.project_id' });

1;

Our table names are all snake case, we are developing with Linux Mint. So I have no clue why DBIC return CamelCase.

[preaction]

It returns camel case because it's the class name (the last part after ::Result::), not the table name. That's what Yancy uses to name the schemas because that's all it can use without breaking the encapsulation of the ORM. Now that I understand, I can fix this properly and write a test.