diesel: Support multiple schemas in diesel.toml

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.

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 21
Comments: 16 (8 by maintainers)

Links to this issue

How to build multi-tenant API (PostgreSQL schemas) efficiently?

Most upvoted comments

Something like the following would likely be beneficial

# For documentation on how to configure this file,
# see diesel.rs/guides/configuring-diesel-cli

[print_schema]
include_schemas = ["schema1", "schema2", "schema3"]
exclude_schemas = ["pg_catalog", "information_schema"] # Implicit defaults include xor exclude
patch_file = ""

[print_schema.schema1]
file = "src/models/schema1.rs"
filter = { except_tables = ["spatial_ref_sys"] }

[print_schema.schema2]
file = "src/models/schema2.rs"
filter = { except_tables = ["ignored_system_table"] }

+15

huhlig on Feb 16, 2019

I would for sure love multiple schema support. If there is an approved direction I’d be happy to try and take it on.

drusellers on Feb 7, 2020

@StuartHadfield It doesn’t matter for me why you comment here, but how. It would be a completely different discussion if you used a different wording in your question, possibly even suggesting that you want to work on this. Again: I consider just asking for updates as rude, as it wastes the time of the maintainer, so stop doing that. Anything that’s relevant for this issue is linked above. If there is no entry for some time, that means there is no movement on that topic for this time. This explicitly includes the fact that this topic is waiting for someone to work on.

(And yes, those last two comments are considered off topic here, so they will be marked as off topic.)

weiznich on Oct 18, 2022

Hi @weiznich, yeah I am asking if there is any movement on a four year old issue that has been accepted, I’m not commenting for my personal satisfaction.

A much more productive reply is “Not as of yet! Would you like to try implementing it?”, or, “Yes, work has started here, but we don’t have a definite date for when it might be released”. Just marking comments from users as off-topic is kinda lame. 😦

StuartHadfield on Oct 18, 2022

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.

sgrif on May 23, 2018