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

Support multiple schemas in diesel.toml #1728

Open
compressed opened this Issue May 23, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@compressed
Contributor

compressed commented May 23, 2018

Versions

  • Diesel: 1.3
  • Database: Postgres

What are you trying to accomplish?

In 1.3, the diesel.toml file has been introduced. In the current form, you can only read tables from one schema. I'd like a way to specify multiple schemas that can all be generated into a single schema.rs file.

Perhaps you could have multiple [print-schema] sections, each one belonging to a different schema, since you may want to apply different filtering depending on the schema. I think all the existing options are good to have available for each schema you want to load from, except probably patch_file since it applies to the whole file.

@sgrif sgrif added the accepted label May 23, 2018

@sgrif

This comment has been minimized.

Member

sgrif commented May 23, 2018

I'm not sure that multiple print-schema sections is the way to go, but I think we need to support this somehow. Agreed that it would need to support separate filters per schema, and that could definitely lead to the conclusion that duplicating that section is the way to go. However, we could also allow filters to specify the schema in the table name. e.g. filter = { only-tables = ["schema1.table1", "schema2.table1"] }

@compressed

This comment has been minimized.

Contributor

compressed commented May 23, 2018

That sounds better to me because, looking again, patch_file and with_docs are universal options that would apply to all schemas. It would certainly make for a shorter and easier to understand file. I'm not sure if you'd want schema specific import_types (I don't use that feature currently).

@sgrif

This comment has been minimized.

Member

sgrif commented May 23, 2018

I don't think we need import_types be schema specific. There's no harm in having the imports used by schema 2 in the tables from schema 1 99% of the time. I'm sure someone out there has a very specific case where this doesn't work, but... that's what patch_file is for.

@trsh

This comment has been minimized.

trsh commented May 24, 2018

I like to keep my structure like /models/table1/model.rs, schema.rs, /models/table2/model.rs,schema.rs. So yes I would also appreciate some scenario, where I can split Large single schema.rs in to multiple ones.

@tcmal

This comment has been minimized.

tcmal commented Jun 16, 2018

Something like [printschema.whatever] with the usual properties could work if it inherited from the base printschema, I can't think of many other ways to do it & support filtering that isn't kinda messy imo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment