in reply to Re: DBD::MariaDB + DBIx::Class = woes
in thread DBD::MariaDB + DBIx::Class = woes

Thank you rbrew for this detailed solution.

I know you are querying the DB, but did you, perchance, see the problem of the auto-incremented PK I mentioned above? (i.e. problem specifying a PK and then problem making it auto-incrementing).

  • Comment on Re^2: DBD::MariaDB + DBIx::Class = woes

Replies are listed 'Best First'.
Re^3: DBD::MariaDB + DBIx::Class = woes
by rbrew (Novice) on May 11, 2024 at 13:08 UTC
    My symptom was similar to yours. When I ran schema loader to generate result classes the primary keys were not being included in the Result Class .pm files and the auto_increment entry was always missing. In addition, the many_to_many, has_many and belongs_to relationships were not included. Also for integer types, the signed/unsigned specification was missing. The edits I describe seems to correct all of those problems. I do not usually generate my database tables from DBIx::Class result classes because I use DbSchema to create my tables and to populate by database. I typically use DBIx::Class::Schema::Loader to generate the result classes for use by my Perl code. I made some more changes as now described in my revised blog posting and the basic functionality of $schema->deploy works. Auto_increment and primary key creation works. What does not seem to work properly are timestamp types where the extra involves ON UPDATE current_timestamp(). Neither does deploying with {add_drop_tables => 1}, in that the deployment fails because tables will not drop before trying to recreate them from the Result Classes. More testing is needed to isolate the problems.
[reply]
      Please do contribute the SQL::Translator changes in a pull request. Don't worry about perfection - I just resolved some 15-year-old bugs in the DBI Postgres parser last summer.
[reply]
[reply]

In Section Seekers of Perl Wisdom