-
Notifications
You must be signed in to change notification settings - Fork 161
Always sort scalar types by name when returning them #417
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I'm not sure how you feel about the |
Itertools avoids allocating a whole vec, but it's very easy to reimplement (see https://github.com/prisma/prisma-engines/blob/fe68ee16ec7694924b82bf075382fa68e69989da/migration-engine/connectors/sql-migration-connector/src/sql_renderer/common.rs#L92 for example) — I'd rather avoid taking on a new dependency so let's add this trait to graphql-client. The PR looks good! |
62054bc
to
37ec1ab
Compare
I updated the PR to do the sorting "by hand". It still has to allocate the |
Actually, looking more closely at the code I think it'd be possible to have this problem with inputs and enums too, so I'll do the same thing for them. |
Previously these were returned in an essentially random order. This would lead to flapping in the generated code when running the client CLI against the same schema multiple times. In the application I'm writing, I check in the generated schema, so this sort of flapping in the generated code creates unwanted noise in the commit history.
37ec1ab
to
b708e80
Compare
The CI failures look to be unrelated to this PR. There is some code in main that isn't properly rustfmt'd. If it got to clippy that would also fail because of some unused struct fields. The prettier failure is also because of files in main that aren't properly formatted. |
ping |
Is this obsoleted by #430 ? |
I think it is |
I don't understand the code base well enough to say if #430 obsoletes this one, but I'm fine with closing this if it does. |
.inputs() | ||
.filter(move |(id, _input)| self.types.contains(&TypeId::Input(*id))) | ||
.collect::<Vec<_>>(); | ||
inputs.sort_by_key(|(_id, input)| input.name.as_str()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using Itertools::sorted_by_key
can avoid the intermediate Vec
.
Ah, I see. #430 probably does resolve this. Tested on |
Previously these were returned in an essentially random order. This would lead to flapping in the generated code when running the client CLI against the same schema multiple times.
In the application I'm writing, I check in the generated schema, so this sort of flapping in the generated code creates unwanted noise in the commit history.
I tested this by hand by running the fixed client against my schema a number of times. This stopped the flapping in the generated code.