-
Notifications
You must be signed in to change notification settings - Fork 213
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
Conversation
…ting in introspection
CodSpeed Performance ReportMerging #3924 Summary
|
…rnings with several repetitions in a group
write!(f, r#"Model: "{}""#, &model)?; | ||
write!(f, ", field(s): [")?; | ||
|
||
let (last, vec_but_last) = vec.split_last().unwrap(); |
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.
.unwrap()
is safe, as vec
is at least a singleton
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.
Iterator::peekable()
is a good way to do this that without unwraps/panics, but I really don't mind doing it this way either.
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 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)
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.
There's an example here:
prisma-engines/schema-engine/connectors/sql-schema-connector/src/introspection_map/relation_names.rs
Line 154 in e9d4b38
let mut cols = fk.constrained_columns().peekable(); |
no need to change here though
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.
Note: I skipped the Rust code
The output looks good!
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.
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; | ||
} |
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 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.
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.
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>, |
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.
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
).
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.
Thank you, I have applied this.
write!(f, r#"Model: "{}""#, &model)?; | ||
write!(f, ", field(s): [")?; | ||
|
||
let (last, vec_but_last) = vec.split_last().unwrap(); |
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.
Iterator::peekable()
is a good way to do this that without unwraps/panics, but I really don't mind doing it this way either.
|
||
result | ||
} | ||
} |
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 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();
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: |
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.
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( |
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.
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::{ |
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.
a little confused by this change, does this have any meaning outside semantics? and on that, what are the semantic benefits here
This PR:
Model: "person", field(s): ["0", "1", ..., "100"]
introspection_tests::views::mysql::invalid_field_names_trigger_warnings
inspired byprisma/introspection-ci
See Slack thread.