Generate constraint/index names as consts

[fenollp]

I'd like to be able to activate some option to obtain const strings in the generated modules. These strings would be for example:

/// Indexes:
// For   "job_pkey" PRIMARY KEY, btree (key)
const JOB_PKEY: &str = "job_pkey";

/// Check constraints:
// For   "modification_date_range" CHECK (creation_date <= modification_date)
const MODIFICATION_DATE_RANGE: &str = "modification_date_range";

or any other naming scheme... My main point is to never having to copy/paste such strings when I'm using on_constraint("..").

[weiznich]

I can see the advantages of having these definitions "somewhere", but it's unclear what exactly you are trying to propose here. Where exactly should these constants be generated? How would they be controlled? Where does the information for these constants come from?

[fenollp]

Hey! Thanks for taking the time.

1. Probably at least within the same module as where tables code is generated. Just as &str consts.
2. Tuning these could happen through diesel:: calls in the generated schema.rs file, which has "patch mechanisms"
3. I don't know much about index name generation. I expect there are implementation differences between engines (pg, mysql, ..) maybe even between engine versions or platforms, but that surely can be >80% handled. I worry about the case where a name conflicts or just when a dice roll is somehow involved in getting an index name. I do hope that the whole process of getting an index's name can just come from reading migrations, I guess.

Do you have info or ideas on this? I understand this doesn't sound realizable.

Are there any plans to "incorporate migrations code more into Diesel"? Or are migrations meant to always be written in plain SQL?

I'm thinking that for this to be able to work means finding a way to add more (enough) info to the schema.rs.
Maybe users could add a call to a macro à la this that describes an index or pkey or check, or at least its name, for a table.
This says there aren't many combinations of constraint types.
These new macros could allow for specifying the meat/logic of each constraint, if you think this direction should be taken, but that's not required here.
From there generating the consts is trivial.
Last point: to make sure a user expressed all of its DB's various constraints, a (maybe existing) CLI command should be added that errors out on a diff between a DB's constraints and the ones expressed in schema.rs.

[weiznich]

To be clear here: I'm not opposed to add something like this. It's just that there needs to be an concrete design for how exactly this would look like, what API is exposed to to the user and where the information are coming from. I'm mainly asking for clarification here as I'm not able to design everything myself. There is just so much time every day.
For this specific feature to be accepted and implemented someone needs to do all the design work and propose a specific API that can be implemented. After that someone needs to implement it. Again, we are open to accept contributions here. The first step would be to propose a concrete user facing API how to express these information in your schema.rs files.