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

Updates conformance comparison report and exception handling #1547

Merged
merged 2 commits into from
Aug 14, 2024

Conversation

johnedquinn
Copy link
Member

@johnedquinn johnedquinn commented Aug 14, 2024

Description

  • Simplifies the UI of the conformance report. Here's the latest report. Here's an example of an older report.
    • I've made the sections easier to distinguish.
    • Enumerated the test cases that are failing/passing.
    • Instead of using green/red emojis for the column names of the table. I'm using them to indicate whether the actual results are good/bad.
    • Used better names for the reports.
    • Used the short hash when possible (while still showing the full hash in the details section).
  • Simplifies the actual logic of report generation
  • Updates the exception handling

Example of how the new green/red emojis are used to denote good/bad instead of using them as labels. It should make it easier for reviewers to read. Here's how it used to be:

Base (legacy) eval +/-
% Passing 90.72% 96.05% 5.33%
✅ Passing 5329 5643 314
❌ Failing 545 232 -313
🔶 Ignored 0 0 0
Total Tests 5874 5875 1

And, here's how it is now:

BASE (LEGACY-B94D328) TARGET (EVAL-B94D328) +/-
% Passing 90.74% 96.05% 5.31% ✅
Passing 5330 5643 313 ✅
Failing 544 232 -312 ✅
Ignored 0 0 0 ✅
Total Tests 5874 5875 1 ✅

License Information

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@johnedquinn johnedquinn marked this pull request as ready for review August 14, 2024 18:38
@johnedquinn johnedquinn requested a review from alancai98 August 14, 2024 18:38
Copy link
Member

@alancai98 alancai98 left a comment

Choose a reason for hiding this comment

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

nice work on the refactor of both the comparison report and test runner exception handling. only left a few minor comments/suggestions

val actual = executor.execute(statement)
executor.toIon(actual)
} catch (t: Throwable) {
thrown = t
Copy link
Member

Choose a reason for hiding this comment

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

Not related to this PR, but since we started enabling the thrown errors to propagate through, I noticed that some of the errors are kinda non-descriptive.

For example, this test run in permissive mode https://github.com/partiql/partiql-tests/blob/9aa7694eb12b4e0e599f4bbfbf4a1b8094b05ad7/partiql-tests-data/eval/query/limitoffset.ion#L250 only outputs the following:

org.partiql.errors.TypeCheckException

We should consider adding some more description for certain error messages.

Copy link
Member Author

Choose a reason for hiding this comment

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

True! While it's not part of this PR, I'll give some insight.

There's actually a reason for the lack of a stack trace -- performance. From my performance evaluation, one thing was clear: fillInStackTrace is insanely expensive on the CPU. The TypeCheckException removes the default implementation of fillInStackTrace. If you'd like more information, you can temporarily comment it out to figure out where it's coming from. Beyond that, you're totally right. More of the TypeCheckExceptions should have a corresponding error message -- though not all instances have them.

val comparison = first.compareTo(second)
return when {
comparison < 0 -> if (positiveDeltaGood) ICON_CHECK else ICON_CIRCLE_RED
comparison == 0 -> ICON_CHECK
Copy link
Member

Choose a reason for hiding this comment

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

nit: wonder if for if there's no diff, we want some neutral indication consider ➖ (:heavy_minus_sign:). ✅ would seem to indicate some good change but perhaps no regression is good?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I played with doing a grey icon, but it started to look a bit cluttered visually. I figured green/red are pretty easy indicators for reviewers that something is good/bad.

@johnedquinn johnedquinn merged commit 5bc82d0 into partiql:v1 Aug 14, 2024
7 checks passed
@johnedquinn johnedquinn deleted the v1-conformance-update branch August 14, 2024 21:44
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.

2 participants