4 ms·

IMO these statements contradict themselves: > Idempotency refers to the ability of an operation to be performed multiple times whilst still yielding the same o

by maname 2y ago

IMO these statements contradict themselves: > Idempotency refers to the ability of an operation to be performed multiple times whilst still yielding the same outcome and > The issue with the above code is that if the event is processed twice the EmailService will send a duplicate email. In other words, the operation (three lines of code) yields the same result (sending an email) after repeated execution, and thus is idempotent isnt it? Or is the point that idempotency is harmful in this case?

phoe-krk 2y ago
> In other words, the operation (three lines of code) yields the same result (sending an email) after repeated execution, and thus is idempotent isnt it? The meaning here is: after the operation is performed at least one time, exactly ONE mail is sent. Note the part "at least one time": it can be one, two, or more.
- maname 2y ago
  thanks, that clicks. "Simply put, we can perform an idempotent operation multiple times without changing the result. Furthermore, the operation must not cause any side effects after the first successful execution." Baeldung got it right.
ReleaseCandidat 2y ago
Yes, the first statement can be easily misunderstood. It could also mean that the operation `f` does not have side effects. What it actually wanted to express is that `f(x) == f(f(x))`.
happytoexplain 2y ago
The world is a system that has state. If two invocations of your function with the same parameters both mutate any part of that state, and nothing else mutated that part in between, then it's not idempotent. In this case, there are now two emails in the recipient's inbox. I.e. "result" refers to state, not actions. "Send one email saying 'hi'" is an action. "There is one email saying 'hi' in their inbox" is a result. There is also usually an implicit limiting scope (except in very pure functional contexts). E.g. just because two invocations both produce entries in an activity log somewhere doesn't usually count as "not idempotent". You can also think of it in terms of declarative vs imperative. 'x = 1' is declarative (and idempotent). 'x += 1' is imperative. YMMV with this use of those terms, though. To oversimplify, an idempotent function is "safe to spam", e.g. if you're not sure it worked the first time, you can do it again without worrying about duplication. A very relevant concept in networked communication. Edit: I should also clarify that "same parameters" includes any state the function reads that is mutable over the scope in which you would like to define idempotency. I.e. if the function reads some external state that might change between calls, that counts as "parameters" in my simplified definition.
- PaulDavisThe1st 2y ago
  > If two invocations of your function with the same parameters both mutate any part of that state, and nothing else mutated that part in between, then it's not idempotent. Still not accurate. What matters is whether N calls to the function changes the state differently than a single call. If not, then the function is idempotent. Another issue with idempotency is that there's an implicit temporal component that is rarely explicitly discussed. Most people don't expect a function to necessarily be idempotent over long periods of time.
  - happytoexplain 2y ago
    >What matters is whether N calls to the function changes the state differently than a single call. I thought "any 2" would be the relevant subset of "N" that you can use to define idempotency in simpler terms. Also, I'm using the phrase "mutate state" as shorthand for your "change state differently", I think. I.e. if two things both change state, then by definition they changed it "differently". If two things both set x to 1, the second one didn't "change state". >there's an implicit temporal component ... idempotent over long periods This sounds a bit like what I mentioned about other things touching state between calls to your idempotent function. Maybe I meant the same thing as you, but used different words?
dragonwriter 2y ago
"outcome" here refers to "resulting state of the world", not "actions which are performed as a result of operation". Which makes it a bad choice of terminology, because while both of those are things for which "outcome" is a natural word choice, the latter is at least as natural of a reading, and is what idempotency is defined in opposition to, so at best the statement is ambiguous on exactly the point it is trying to clarify.

by maname 2y ago

phoe-krk 2y ago

> In other words, the operation (three lines of code) yields the same result (sending an email) after repeated execution, and thus is idempotent isnt it? The meaning here is: after the operation is performed at least one time, exactly ONE mail is sent. Note the part "at least one time": it can be one, two, or more.

maname 2y ago
thanks, that clicks. "Simply put, we can perform an idempotent operation multiple times without changing the result. Furthermore, the operation must not cause any side effects after the first successful execution." Baeldung got it right.

ReleaseCandidat 2y ago

Yes, the first statement can be easily misunderstood. It could also mean that the operation `f` does not have side effects. What it actually wanted to express is that `f(x) == f(f(x))`.

happytoexplain 2y ago

The world is a system that has state. If two invocations of your function with the same parameters both mutate any part of that state, and nothing else mutated that part in between, then it's not idempotent. In this case, there are now two emails in the recipient's inbox. I.e. "result" refers to state, not actions. "Send one email saying 'hi'" is an action. "There is one email saying 'hi' in their inbox" is a result. There is also usually an implicit limiting scope (except in very pure functional contexts). E.g. just because two invocations both produce entries in an activity log somewhere doesn't usually count as "not idempotent". You can also think of it in terms of declarative vs imperative. 'x = 1' is declarative (and idempotent). 'x += 1' is imperative. YMMV with this use of those terms, though. To oversimplify, an idempotent function is "safe to spam", e.g. if you're not sure it worked the first time, you can do it again without worrying about duplication. A very relevant concept in networked communication. Edit: I should also clarify that "same parameters" includes any state the function reads that is mutable over the scope in which you would like to define idempotency. I.e. if the function reads some external state that might change between calls, that counts as "parameters" in my simplified definition.

PaulDavisThe1st 2y ago
> If two invocations of your function with the same parameters both mutate any part of that state, and nothing else mutated that part in between, then it's not idempotent. Still not accurate. What matters is whether N calls to the function changes the state differently than a single call. If not, then the function is idempotent. Another issue with idempotency is that there's an implicit temporal component that is rarely explicitly discussed. Most people don't expect a function to necessarily be idempotent over long periods of time.
- happytoexplain 2y ago
  >What matters is whether N calls to the function changes the state differently than a single call. I thought "any 2" would be the relevant subset of "N" that you can use to define idempotency in simpler terms. Also, I'm using the phrase "mutate state" as shorthand for your "change state differently", I think. I.e. if two things both change state, then by definition they changed it "differently". If two things both set x to 1, the second one didn't "change state". >there's an implicit temporal component ... idempotent over long periods This sounds a bit like what I mentioned about other things touching state between calls to your idempotent function. Maybe I meant the same thing as you, but used different words?

dragonwriter 2y ago

"outcome" here refers to "resulting state of the world", not "actions which are performed as a result of operation". Which makes it a bad choice of terminology, because while both of those are things for which "outcome" is a natural word choice, the latter is at least as natural of a reading, and is what idempotency is defined in opposition to, so at best the statement is ambiguous on exactly the point it is trying to clarify.