-
Notifications
You must be signed in to change notification settings - Fork 100
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
feat: Add overview section to the Json report #1531
feat: Add overview section to the Json report #1531
Conversation
✅ Rule acceptance tests passed. |
* Fields names used here will be the same as in the generated json file. | ||
*/ | ||
@SuppressWarnings("unused") // The fields of this class are only read by Gson when serializing. | ||
public class JsonReportSummary { |
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.
Hey, I had a macro comment on this class.
This class defines the exported API for the JSON report summary. As such, identifiers used here should be stable, since folks external users will be depending on this API. However, this summary depends on a number of identifiers export from FeedMetadata
and AgencyMetadata
, two classes that were written primarily as UI presentation model classes. As such, I think there is a risk someone might make a change to one of those UI presentation classes, not realizing it would impact the exported JSON api.
For example, the key names in feedInfo
below, any of the data in AgencyMetadata
, the keys in counts
, and the identifiers in gtfsComponents
. They'd all ideally be defined fields or enums, where it's very clear that changing a value would change the exported API.
Does that feedback make sense?
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 does thanks.
For the class AgencyMetadata, would you suggest I use @SerializedName annotation with a comment explaining why it's there? Or extract the data in a Map and use defined fields for the key.
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.
Created classes devoted to the json generation with controlled fields and copied values from the existing classes.
Also added some string constants used in the Html and Json generation code so it's obvious changing the string could have an effect in the Json report code.
Continued using gtfsComponents directly. We will have to be avoid changing the component names or document it properly.
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 changes look good. Thanks!
Doesn't have to be in this PR, but long-term, I think it would be more valuable to have GTFS Components modeled as an enum internally, not a string. It might ultimately be rendered as a string, but I think a enum would be more practical for long-term programatic access.
main/src/test/java/org/mobilitydata/gtfsvalidator/report/model/JsonReportGeneratorTest.java
Outdated
Show resolved
Hide resolved
main/src/test/java/org/mobilitydata/gtfsvalidator/report/model/JsonReportSummaryTest.java
Outdated
Show resolved
Hide resolved
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.
@@ -229,18 +233,31 @@ public static void exportReport( | |||
"Error creating output directory: %s", config.outputDirectory()); | |||
} | |||
} | |||
SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd 'at' HH:mm:ss z"); |
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 see here you are using SimpleDateFormat. I recommend using DateTimeFormatter. DateTimeFormatter is a replacement for the old SimpleDateFormat that is thread-safe and provides additional functionality. I recommend using the new Date Time API introduced in Java 8.
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.
This piece of code already existed and was simply moved from main/src/main/java/org/mobilitydata/gtfsvalidator/report/HtmlReportGenerator.java.
I would prefer at this point to keep it as is.
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 see that the GtfsDate is already using LocalDate which is introduced with DateTimeFormatter in the new java 8 date time API. I'm ok with keeping it for now for this issue, but shall we open an issue about updating to the java 8 data time API since it's more immutable and threadsafe than the old ones? @davidgamez
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 was willing to give it a go, but DateTimeFormatter had trouble interpreting the part of the pattern related to time zone.
Since like I said the date related code in this PR is actually some code that was moved and not modified, I prefer to keep it the way it is.
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 see. I agree to keep it the way it is. I can open a new issue about this, maybe use ZonedDateTime for GtfsDate.
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.
In reality I don't think you should open an issue about this.
The fact that it's not thread safe is irrelevant here because we are creating and using the formatter in the same thread. As for extra functionalities, we don't need them here.
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: |
✅ Rule acceptance tests passed. |
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.
LGTM
@isabelle-dr If you have time could you take a look at the exemple summary in the first comment of this PR: #1531 (comment) Also @qcdyx mentioned this in her review #1531 (review):
Do you have an opinion on this? The N/A is also present in the json report summary. |
@jcpitre Hello! Isabelle's off for the rest of the week so I can share comments here to unblock this. I downloaded the JAR file from this branch's Test Package Document action to test this on a few reports.
|
Summary:
Closes #1503
Added an overview section to the JSON report according to https://docs.google.com/document/d/157X9lMTkZHH7oYxK1fYPiY-rMh_VWyPMW_s9wImOP-I/edit
Expected behavior:
There should be this summary section in the JSON report:
Note that the summary section is not used for validation result comparison.
Please make sure these boxes are checked before submitting your pull request - thanks!
gradle test
to make sure you didn't break anything