Make codegen output deterministic

[scotttrinh]

@jaclarke

Can you give some detail about which parts of the code gen are non-deterministic? All three generators? Do you have an suspicions about what the reason for the non-determinism might be? Code ordering due to parallelism or something like that?

[jaclarke]

If I remember correctly (I should have added a description to this issue), the main reason behind this issue was that when you change your schema and re-generate the querybuilder or interfaces, the output is ordered based on whatever arbitrary order edgedb returned the type objects in the introspection query. So if you're checking these generated files into git, there's a bunch of diffs that are just the object type defs/interfaces in a different order, but otherwise exactly the same. I think sprinkling a few order by .name's into the introspection queries should fix this?

The other (probably harder to fix) part of this issue is around where we include object type ids in the generated code. Since these type ids are randomly generated by edgedb when the schema migrations are applied, they are stable for a given instance, but re-generating the qb/interfaces from a different instance (even with the same schema) will output different ids.

[tomnz]

Would like to add a +1 for this - the order of fields is unstable across developer machines for us. It seems to perhaps be tied to the order that the fields were created on the database. A developer who joined us recently has a fresh database created using migrations that were squashed some time ago, and it seems to have given him a different ordering of fields; this creates some churn every time we send a PR.

Maybe not the best practice to commit the generated files, but it makes some things easier for us operationally.

[jackfischer]

+1 that the best practice is to generate the files in CI but sans that investment, our diffs are littered with meaningless noise because of the regeneration across different developer environments.