OptimisticLockException when executeStatement doesn't actually update anything

[alcohol]

Just looking for some insight/feedback on what we were doing wrong.

We basically have a class with helper methods which look like such:

public function updateEntity(Entity $e, float $x): void
{
    $this->entityManager->wrapInTransaction(
        static function (EntityManagerInterface $em) use ($e, $x): void {
            $e = $em->find(Entity::class, $e->getId(), LockMode::PESSIMISTIC_WRITE);
            $e->setSomething(max(0, $e->getSomething() + $x));
        }
    );
}

These modify versioned (timestamp) entities.

Yet we still kept running into OptimisticLockExceptions.. which puzzled us initially.

It took a while for us to figure out that sometimes we would be updating the same entity, with the same resulting value (0), within the same second, thus executeStatement in \Doctrine\ORM\Persisters\Entity\BasicEntityPersister::updateTable actually returned 0 rows affected, which triggered the OptimisticLockException.

We implemented some simple guards to prevent these exceptions, e.g.

if ($e->getSomething() === max(0, $e->getSomething() + $x)) { 
    return; 
}

Alternatively we could have switcher to integer versioning instead of timestamp I reckon, but that seemed more of a hassle with migrations and what not.

Is there something else we might have overlooked?

[alcohol]

So.. we ran into sort of the same issue again today. This time because due to runtime calculations, we wound up with values modified to a four decimal precision, but since the database only stores two decimal precision for the column in question, the row wasn't actually updated. Again, something we can guard against in an ugly way.. but I'm really starting to wonder if this actually warrants an OptimisticLockException. Any input on this @Ocramius ?