What is the corresponding SQL for joinable!

[crusty-dave]

I have manually added the macros into the schema with my table! macros.

If I run migrations, it will overwrite them, so I am wondering what SQL statements I need to place in my up.sql to get the joinable! macro to be generated? A web search has so far proved fruitless, perhaps a diesel example exists?

(I am using PG in case it matters.)

Update:

It seems that I can add CONSTRAINT xxx FOREIGN KEY, but it doesn't produce the desired result:

CREATE TABLE Main_Table
(
    my_key     Text primary key,
    created_at timestamptz NOT NULL
);

-- The tenant collector credentials needs to maintain the client secret as encrypted data
-- so that the tenant's configuration can be regenerated if needed.

CREATE TABLE Main_Table_Credentials
(
    tenant Text primary key,
    user Text NOT NULL,
    hashed_secret Text NOT NULL,
    CONSTRAINT FK_Main_Table FOREIGN KEY (my_key) REFERENCES Main_Table
);

Also, is there any way to have diesel preserve CamelCase for table names?

TIA,
-Dave

[crusty-dave]

It seems that I can put joinable! in my models.rs file, however, then it is a bit divorced from the SQL. Perhaps not a big deal as the models.rs file needs to be edited if table names change. I specifically saw a code example where joinable! was added to the schema.rs file, which is why I originally placed mine there.

The following seems to show it in other than the schema.rs file:
https://docs.diesel.rs/diesel/macro.joinable.html

Also, it would be nice if -- comments in the SQL were copied as Rust doc comments into schema.rs, and consecutive comments on the top lines of the file should be treated as //! module comments.

[weiznich]

Seems like your foreign key constraint is not considered to be valid according to the diesel internal implementation. That's most likely due to the reason that the constrain is not attached to any column in your credentials table.

For the other questions:

• Diesel gets names from the information schema. Postgres only provides the lower case names there, so there is no way to get the original name from there.
• The information schema does not contain any comments from the migration files. Therefore we do not have any access to them.