How to compose multiple crates

[TheNeikos]

Heya! 👋

I'm currently trying to refactor an application I am building into multiple pieces. One of those pieces can be shared with other apps I am writing.

So I was hoping I could do the naive thing of:

• Create a library crate, and write the base parts with diesel
• Have other crates depend on it and use it as if it was a 'module' before

I did run into some problems though, mostly related to generating the schema.

I was hoping I could:

• Run the migrations of the common library: diesel migration run --migration-dir ../common/migrations
• Exclude in diesel.toml the generation of tables that come from the common crate
• Simply continue coding as before

But this also causes the join! and related macros to not be generated. Which makes sense, they don't have the needed tables.

I was able to still get it working by manually writing those join lines and adding a pub(crate) use common::schema::* at the top of the file.

My question to the community/maintainers is then, am I missing something here that could make this a bit less manual?

I was hoping I could say 'exclude generation of the table! but keep the joins', but its either/or. Similarly, adding the use at the of the file. I was hoping that 'import-types' would do the trick, but that seems to be mostly for SQLTypes-related things.

I was thinking of some additions that wouldn't be just for my specific usecase (and would offer help implementing them) akin to:

• Allow generating join/etc macro statements with a 'trust me' kind of setting
• Allow specifying header statements

The latter is not suuper important, as patch files are fairly robust about inserting things at the top. So that's not a biggie. But allowing generation of join macros would be a big help in reducing patch mismatches and otherwise confusing messages.

[TheNeikos]

Going through the code, one could add a new config to diesel-cli in the print_schema section akin to allow_unknown_table_names = [ "common_table" ].

This could passed into the function here:

diesel/diesel_cli/src/infer_schema_internals/foreign_keys.rs

Lines 39 to 50 in 7629365

	.filter(|fk|{
	if !safe_tables.contains(&fk.parent_table) {
	tracing::debug!(?fk, "Remove foreign key constraint because it references a table not in the outputted schema");
	}
	safe_tables.contains(&fk.parent_table)
	})
	.filter(|fk| {
	if !safe_tables.contains(&fk.child_table) {
	tracing::debug!(?fk, "Remove foreign key constraint because it references a table not in the outputted schema");
	}
	safe_tables.contains(&fk.child_table)
	})

Which would then check that if the table doesn't exist, but is in the allow_unknown_table_names set, it still generates it.

That wouldn't be enough to make it work yet, as the Table is already filtered out. But it should not require a large change from what I can see.

[weiznich]

As you already noticed that's something that is currently not supported by diesel cli. I'm open to add something there, but it's unclear for me how exactly that would look like to keep it general and usable. Unfortunately I do not have any capacity for such design work at the moment so such a proposal would need to be written by someone else.

That written: There is one other approach you could try: Putting the schema.rs file in it's own crate and let all "model" crates depend on that crate. This gets you a common schema and allows you to split up everything else. That's what I know other projects are currently doing to keep crates small.