CLI: Add a subcommand to print db schema as `table!` calls

[killercup]

I've been thinking about adding a diesel_cli subcommand to use infer_schema to print out the current schema as calls to table!.

The motivation is that for a large application I'd want to have the current schema somewhere in the repo and not just be the result of a bunch of migrations. (This might make it easier to join an existing diesel project as well.)

First draft for the CLI usage:

diesel-schema
Commands for operating on the database's schema

USAGE:
    diesel schema [FLAGS] [OPTIONS] [SUBCOMMAND]

FLAGS:
    -h, --help    Prints help information

OPTIONS:
        --database-url <DATABASE_URL>    Specifies the database URL to connect to. Falls back to the DATABASE_URL environment variable if unspecified.

SUBCOMMANDS:
    help     Prints this message
    print    Print the database's schema as code that can be used in a diesel-based project.

[iamsebastian]

Would be a great addition, as I write a new Postgresql-rust/Nickel project, based on an existent MySQL-PHP project with dozens of tables.

[sgrif]

@iamsebastian Is there a reason you're unable to use infer_schema! for that?

[iamsebastian]

Am I able to print out the schema with the infer_schema! macro, @sgrif ?

[sgrif]

No, what I mean is that I'm curious why you need to print out the schema instead of inferring it.

[iamsebastian]

Because sometimes, as I started to use rust & diesel.rs, I struggled around if I had chosen the correct types, that match the types defined in the different postgres-tables (I migrated freshly to a postgres database from our mysql-production database).

[bronson]

I also hope for the ability to print the schema. Rails's schema.rb has saved my bacon a number of times when migrations diverged for whatever reason ( a dev ran a migration on a branch but it changed when hitting master, etc).

Committing schema.rb to the source tree makes it really easy to see if the user's database matches what the code expects. Without it, database issues become more of a poke-and-pray operation.

[marcusball]

Regarding a reason why one might not want to use infer_schema!: I believe this subcommand would solve an issue I encountered a few weeks ago—correct me if this wouldn't.

I wanted to write a small utility for an existing production database, so I decided to try diesel for it. However, infer_schema! failed for me because some of the tables in the existing database are (or were) unsupported by diesel because they had zero or 2+ rows constituting primary keys. This subcommand—and, admittedly, knowledge of the table! macro—would have helped me only interact with the specific tables I wanted, rather than having to infer the whole database schema.

[sgrif]

infer_table_from_schema! would work for that as well

[golddranks]

Let's say that I have to build my project in some environment that, for reason or another, I'm unable to install Postgres in. Does this make possible for me to print the schema as rust source code in my dev environment, and distribute that as a source code file to get rid of the Postgres dependency in the build environment?

[killercup]

Yes, @golddranks. Only the infer_* macros (like infer_schema!) connect to the database at build time. Using table! declarations (like the ones output by this cli command) will allow you to build your diesel project from sources alone.

(Of course, you'll need to personally make sure your db schema is correct/up-to-date if you don't use the infer_* macros, just like with any other ORM.)

[sgrif]

Just to expand on that, I do want to provide a function that verifies that the schema matches what is expected at runtime