-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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 ExecutionContext
dirty flag set to false on same value put or null put
#4691
base: main
Are you sure you want to change the base?
Conversation
@GGHDMS Please sign the Contributor License Agreement! Click here to manually synchronize the status of this Pull Request. See the FAQ for frequently asked questions. |
@GGHDMS Thank you for signing the Contributor License Agreement! |
ExecutionContext
dirty flag set to false on same value put
05e79f3
to
b4f4111
Compare
This should also be in the |
One of the old tests is wrong too: Lines 94 to 97 in cf44ca8
|
ExecutionContext
dirty flag set to false on same value putExecutionContext
dirty flag set to false on same value put or null push
Thank you for the feedback! @mjwiq I have addressed the issue raised in #4692 with this PR. Specifically, I have modified the else branch to ensure that when null is pushed, it does not cause the dirty flag to be incorrectly set to false. Additionally, I have corrected the old test case that was not accurately reflecting the intended behavior. Please let me know if there are any further adjustments needed. |
ExecutionContext
dirty flag set to false on same value put or null pushExecutionContext
dirty flag set to false on same value put or null put
context.putString("1", "test"); | ||
assertTrue(context.isDirty()); | ||
context.putString("1", null); // remove an item that was present | ||
assertTrue(context.isDirty()); | ||
context.putString("1", null); // remove a non-existent item | ||
assertFalse(context.isDirty()); | ||
assertTrue(context.isDirty()); |
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.
By changing this line you change the meaning of the test. I think it would be better to clear the dirty flag before setting it to null for the second time
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.
actually testing that it stays dirty when inserting null twice could then be done in its own test or testDirtyWithDuplicate
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 made some adjustments to the test based on the feedback. I added a step to clear the dirty flag before trying to remove an already non-existent item. This way, the test clearly checks that the dirty state doesn’t change in that situation. I think it makes the intent of the test more explicit and separates the different scenarios, making it easier to understand.
@@ -124,11 +125,18 @@ public void putDouble(String key, double value) { | |||
public void put(String key, @Nullable Object value) { | |||
if (value != null) { | |||
Object result = this.map.put(key, value); | |||
this.dirty = result == null || !result.equals(value); | |||
boolean newDirty = result == null || !result.equals(value); |
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.
Minor nitpick, but I'd prefer a single line change this.dirty = this.dirty || result == null || !result.equals(value);
(and similar for the else case)
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 didn't think one line of code was intuitive, so I made it through newDirty
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 guess that's a personal thing then. I find the or statements easier to read. Let's see if we get a 3rd opinion from the maintainers
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 understand your point, and I think it’s a good idea to get more opinions. I chose this approach because I wanted to explicitly handle situations where the state changes from true to false, ensuring that it doesn’t happen unintentionally.
7401f7e
to
0b5a670
Compare
0b5a670
to
2c98c7d
Compare
Just curious, are there any UT that proved that the I am curious about this because the previous issue #2020 (comment) mentioned this. |
Description
Resolved an issue where the
dirty
flag was incorrectly set tofalse
when aput
operation used the same value as the existing one or when null was pushed. Now, the flag remains true if a prior change has occurred.Solution
Adjusted the
put
method logic to correctly handle value comparisons:Fix #4685 #4692