This repository has been archived by the owner on Oct 9, 2023. It is now read-only.
Carry over hash value for all literal types in remote caching #378
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you for opening this pull request! 🙌 These tips will help get your PR across the finish line:
|
eapolinario
reviewed
Jul 17, 2023
|
|
||
| // Ensure that hash values on maps and collections are carried over | ||
| // into representing literals. | ||
| func TestHashCarryOnContainers(t *testing.T) { |
There was a problem hiding this comment.
can you move these tests to the table-tests in TestHashLiteralMap_LiteralsWithHashSet instead?
There was a problem hiding this comment.
Done in f4d830e.
Previously, the hash set on an input literal would be ignored if the literal was of either the `Collection` or `Map` type. This is fixed here by moving the hash-checking branch up in front of the special type logic, so that an empty literal with hash is constructed in either case if a hash is found. Adds a regression test to verify the hashes are carried over into the representer literals for both map and collection types. Signed-off-by: Nicholas Junge <nicholas.junge@web.de>
Codecov Report
@@ Coverage Diff @@
## master #378 +/- ##
==========================================
+ Coverage 62.89% 64.30% +1.41%
==========================================
Files 154 154
Lines 13029 10563 -2466
==========================================
- Hits 8195 6793 -1402
+ Misses 4221 3157 -1064
Partials 613 613
Flags with carried forward coverage won't be shown. Click here to find out more.
|
eapolinario
approved these changes
Jul 18, 2023
eapolinario
pushed a commit
that referenced
this pull request
Sep 6, 2023
Previously, the hash set on an input literal would be ignored if the literal was of either the `Collection` or `Map` type. This is fixed here by moving the hash-checking branch up in front of the special type logic, so that an empty literal with hash is constructed in either case if a hash is found. Adds a regression test to verify the hashes are carried over into the representer literals for both map and collection types. Signed-off-by: Nicholas Junge <nicholas.junge@web.de>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR
Previously, the hash on an input literal would be ignored if the literal was of either the
CollectionorMaptype. This is fixed here by moving the hash-checking branch up in front of the special type logic, so that an empty literal with hash is constructed in either case if a hash is found.Adds a regression test to verify the hashes are carried over into the representer literals for both map and collection types.
Type
Are all requirements met?
Complete description
See the discussion in flyteorg/flytekit#1720 for the problem statement. This PR is a direct follow-up.
The remote cache fix was missing from that PR, and that is exactly what is added here. The code here is the same fix approach, just in Go this time.
Tracking Issue
N/A