We had a discussion recently about “idempotency” – about what it meant, and whether it was an appropriate term to use given its unfamiliarity outside of mathematics and computer science. The following is a short note I circulated with the intention of clarifying the term with a few examples.
nilpotent – “no power”: has no side-effects
idempotent – “same power”: doing it repeatedly has the same side-effect as doing it just once
pluripotent – “many powers”: doing it repeatedly may produce different side-effects each time
1) An SQL SELECT statement is nilpotent, because it doesn’t change the database.
2) A plain SQL UPDATE statement is idempotent:
UPDATE Foo SET bar='baz' WHERE quux = 'xyzzy';
3) But this fancy SQL UPDATE statement is pluripotent:
UPDATE Foo SET count = (SELECT max(count) FROM Dual) + 1
4) In REST,
- GET is nilpotent
- PUT is idempotent
- DELETE is idempotent
- POST is pluripotent
5) In Bash,
echo "foo" > fileis idempotent
echo "foo" >> fileis pluripotent
6) In the monoid of sets, with set union ∪ as the addition operator (+) and the empty set ∅ as the unit (e),
A + e = A (adding e is nilpotent, because A ∪ ∅ = A)
A + B + B = A + B (adding B is idempotent, because A ∪ B ∪ B = A ∪ B)
Why we care
Idempotency is a useful property for an operation to have if several agents might attempt to carry it out at once. This happens especially in distributed systems. Instead of trying to co-ordinate multiple writes from different agents, you just let them all go ahead, since duplicates are harmless.