You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would get rid of a lot of complexity. It would also reduce the chance of things that have been big problems before: trigger bugs, and queries that can't efficiently use indexes.
Diesel's 32 column limit makes this hard. The first thing that should be done is to create a crate with just the schema.rs file, enable the 64 columns feature, apply the changes in schema.rs, and measure the incremental compile time difference using cargo timings. One of these things about the compile time increase caused by the 64 columns feature might be revealed:
It's not as bad as before
It's outweighed by a compile time decrease caused by the reduced amount of table pairs generated by the allow_tables_to_appear_in_same_query macro
The text was updated successfully, but these errors were encountered:
Yes the compile time increases directly after enabling the 64 column feature, no matter if you use them or not. Its because diesel has to generate a lot more code (macros?) to handle these extra columns. So to test the compile time difference, simply add 64 column feature to Lemmy's cargo.toml.
This would get rid of a lot of complexity. It would also reduce the chance of things that have been big problems before: trigger bugs, and queries that can't efficiently use indexes.
Diesel's 32 column limit makes this hard. The first thing that should be done is to create a crate with just the
schema.rs
file, enable the 64 columns feature, apply the changes inschema.rs
, and measure the incremental compile time difference using cargo timings. One of these things about the compile time increase caused by the 64 columns feature might be revealed:allow_tables_to_appear_in_same_query
macroThe text was updated successfully, but these errors were encountered: