Hi,

I cloned your repo, and used your /accounts app to test. I used DB params for an existing Postgres DB I have. (During installation I noticed that I was getting an error about a too-low version of SQL::Translator (>= v0.11018 required), so I upgraded to v1.60.)

Commenting out the line $connection->deploy(); allowed the app to start and return and render the login page.

I added the line use Data::Dumper; warn Dumper $connection->deployment_statements; and it produced the following output:

$VAR1 = '--
-- Created by SQL::Translator::Producer::PostgreSQL
-- Created on Fri Jul 26 08:54:26 2019
--
';
[download]

I am not an expert on building DBIx schemas manually and then applying them to storage. I always go the other way. I don't mind using a heavy ORM layer like DBIx, but *I* want to be in control of my DB schema. So I usually write a schema file in SQL, then use it to create a DB, then run dbic_dump to create the DBIX schema file(s) in my app. Perhaps you could try this way around, building your DB and then telling DBIx to go from there.

Hope this helps!

Thank you for your reply! I do have the database already created but i saw people creating a schema in their app and then deploy it. The schema class is actually a file in the project that i use, so the schema should dump itself if that makes sens xD. I'm a beginner in perl and mojolicious. With that in mind, how can i dump the schema of my db and use it in the app?

I think this is what you want: dbicdump. But I’m not sure I’m following the problem correctly. You can also load a schema dynamically with DBIx::Class::Schema::Loader but I think that’s false economy; it ends up being more work over time to tweak than dumped code files and it imposes a pretty big startup penalty.

Yes, it makes sense, sorta, and as I said I prefer to work that way. Start with a database and then have DBIx::Class build the schema files from that, rather than the other way round. Using dbicdump you can repeatedly dump your database to schema files, as the DB schema changes, even if you add custom code to the files, since the dumper preserves your changes.

Example of a dump statement:

$ dbicdump -o dump_directory=./lib -o components='[q{InflateColumn::Da
+teTime}]' -o preserve_case=1 MyClass::MyDB::Schema dbi:mysql:MyDB:loc
+alhost:3306 -o overwrite_modifications=1 db_user db_password
[download]

(Note that the scary-looking "overwrite_modifications" refers to manual changes you may have made to the autogenerated section of the schema file (which you should never do), and not to the modifications you make to the section below the marker indicating it is safe to do so.)

---

Addendum: I will note that as a beginner in Perl and Mojo, adding DBIx to the mix is maybe making your life more difficult than it need be. If I were to suggest a choice it would be to build with the more open Dancer2 and use the simple Dancer2::Plugin::Database plugin. Then your app code can just do something like:

get '/user/:name' => sub {
    database->quick_select('users', { name => params->{name} });
};
[download]

DBIx is nice when you really need an ORM, i.e. when your app gets complex enough to merit it because you have a bunch of objects flying around.

# Database with tables related by foreign key
# route handler subclassed from somewhere or consuming a DB role
# pseudocode
get '/user/:name/hobby' => sub {
    my $user = $self->db_rs('MyDB', 'Users')->find({ name => params->{
+name} });
    return $user->hobby;
};
[download]

Hope this helps!



The way forward always starts with a minimal test.

From looking at SQL::Translator, I don't see any convenient way of having its progress through creating the SQL statements for your schema.

I would start out by trying to use the sqlt tool to dump the existing schema. Maybe SQL::Translator does not like it that you have no schema yet.