Skip to content
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

fix(schema-engine): recovered "chosen data" / "original data" formatting in introspection #3924

Merged
merged 10 commits into from
Apr 27, 2023

Conversation

jkomyno
Copy link
Contributor

@jkomyno jkomyno commented Apr 26, 2023

This PR:

  • normalizes name of entries in introspection warnings
  • organizes introspection warnings that can result in long repetitions of different field values for the same fixed key into "groups". This results in something like: Model: "person", field(s): ["0", "1", ..., "100"]
  • adds a mysql test introspection_tests::views::mysql::invalid_field_names_trigger_warnings inspired by prisma/introspection-ci

See Slack thread.

@codspeed-hq
Copy link

codspeed-hq bot commented Apr 26, 2023

CodSpeed Performance Report

Merging #3924 fix/introspection-formatting-and-grouping (075b453) will not alter performances.

Summary

🔥 0 improvements
❌ 0 regressions
✅ 6 untouched benchmarks

🆕 0 new benchmarks
⁉️ 0 dropped benchmarks

write!(f, r#"Model: "{}""#, &model)?;
write!(f, ", field(s): [")?;

let (last, vec_but_last) = vec.split_last().unwrap();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.unwrap() is safe, as vec is at least a singleton

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Iterator::peekable() is a good way to do this that without unwraps/panics, but I really don't mind doing it this way either.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't quite understood how we could apply Iterator::peekable() in this scenario, but I'm happy to see that in action (if not for this PR, maybe for future ones)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an example here:

no need to change here though

@jkomyno jkomyno added this to the 4.14.0 milestone Apr 26, 2023
Copy link
Member

@Jolg42 Jolg42 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I skipped the Rust code

The output looks good!

Copy link
Contributor

@tomhoule tomhoule left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functionally this looks good, but introducing two new traits for this is more complexity than is warranted. I'm open to discussion (I may have missed something) / pairing.


/// Formats the grouped items in a compact, human-readable way.
fn fmt_group(&self, f: &mut fmt::Formatter<'_>, key: &K, value: &[&V]) -> fmt::Result;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be an impl Display for GroupBy<ModelAndField> { ... } (etc.) instead of a new trait. The formatting done in render_warnings_grouped could be a helper function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I have implemented this.

/// Fields having an empty name.
pub fields_with_empty_names_in_type: Vec<TypeAndField>,
pub fields_with_empty_names_in_type: GroupBy<TypeAndField>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These can stay Vec<ModelAndField> and we don't need the new WriteOnlyVec trait if we go with the previous suggestion (we'd just wrap in GroupBy at the last moment in render_warnings_grouped).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, I have applied this.

write!(f, r#"Model: "{}""#, &model)?;
write!(f, ", field(s): [")?;

let (last, vec_but_last) = vec.split_last().unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Iterator::peekable() is a good way to do this that without unwraps/panics, but I really don't mind doing it this way either.

@jkomyno jkomyno marked this pull request as ready for review April 27, 2023 13:56
@jkomyno jkomyno requested a review from a team as a code owner April 27, 2023 13:56
@janpio janpio requested a review from tomhoule April 27, 2023 14:16

result
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant we could remove the whole trait, and replace the lines that just call group_by() with something like let grouped: BTreeMap<_, _> = self.iter().map(|mf| (&mf.model, mf)).collect();

@jkomyno jkomyno merged commit 15a4f29 into main Apr 27, 2023
52 checks passed
@jkomyno jkomyno deleted the fix/introspection-formatting-and-grouping branch April 27, 2023 15:37
let expected = expect![[r#"
*** WARNING ***

These fields were commented out because their names are currently not supported by Prisma. Please provide valid ones that match [a-zA-Z][a-zA-Z0-9_]* using the `@map` attribute:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this something we want to separate out? rather than having one heading for commented out fields and then ordering / sorting them from there, so e.g. still keeping the two models, and then the two views etc

@@ -134,19 +276,19 @@ impl fmt::Display for Warnings {
f,
)?;

render_warnings(
render_warnings_grouped(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not immediately clear to me how the scaffolding for render_warnings_grouped works. I.e. the workflow for adding new warnings - or editing previous warnings - that we want grouped. The change that @tomhoule called out does seem a lot simpler to me

@@ -1,5 +1,8 @@
use crate::introspection_pair::ViewPair;
use schema_connector::{warnings as generators, Warnings};
use schema_connector::{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a little confused by this change, does this have any meaning outside semantics? and on that, what are the semantic benefits here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants