-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: foreign keys use wrong table name, part 2 #112
Comments
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. |
Our result classes have nothing special:
Our table names are all snake case, we are developing with Linux Mint. So I have no clue why DBIC return CamelCase. |
It returns camel case because it's the class name (the last part after |
DBIx::Class result classes do not need the same name as the table, though that's what we use in Yancy's tests to make the DBIx::Class schema look exactly the same as all the other schemas. When the result class has a different name, we want to use that name to avoid breaking the encapsulation of the ORM (the underlying table is not useful information, since it may change). Thanks @mario-minati for help debugging this! Fixes #112
[Fixed] - Fixed missing $match parameter in OpenAPI spec for list actions. Thanks @mario-minati for reporting this! [Github #114] - Added a few more i18n strings to the lexicon. - Fixed DBIx::Class backend not finding schemas and foreign keys when the result name did not match the table name. Thanks @mario-minati for help debugging this! [Github #112]
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;
.The text was updated successfully, but these errors were encountered: