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).
| [reply] |
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] |
rbrew++
thank you, I have finally managed to follow your detailed guide in the link you posted above and tested my quite complex app and can report that all is well as far as functionality and testing is concerned.
bw, bliako
| [reply] |