Idempotency and its friends

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.

Potencies

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

Examples

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,

  • cat is nilpotent
  • echo "foo" > file is idempotent
  • echo "foo" >> file is 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.