La raison WATCH n'est pas exposé directement en raison de la façon dont SE.Redis est conçu pour multiplexer les commandes de différentes piles d'appels sur une seule connexion. Cela rend nécessaire que tout travail de transaction soit très étroitement géré.
Je ne sais pas exactement quel serait le but de "inchangé" par lui-même , sans comparaison avec une valeur connue - sinon vous créez simplement une condition de concurrence. Il serait certainement possible d'ajouter un support pour cela, mais j'aimerais vraiment comprendre d'abord le cas d'utilisation attendu. Pouvez-vous expliquer ?
Re votre édition; votre exemple préféré (le dernier) n'est tout simplement pas possible avec redis - rien à voir avec SE.Redis ; si vous faites un GET dans un MULTI , vous n'obtenez pas la réponse avant le EXEC se termine - vous ne pouvez donc pas utiliser la valeur dans le SET :il n'est pas encore disponible .
Si ce n'était pas pour le multiplexage, vous pourriez réorganiser un peu votre deuxième exemple (basé sur ce que fait SE.Redis) :
WATCH key
val = GET key
MULTI
val = val + 1
SET key $val
EXEC
c'est le typique utilisation de WATCH :vous regardez les choses que vous interrogez à l'avance, alors vous savez que {key} est inchangé pendant cette boucle (ou du moins, la transaction aura avorté ; pas d'état incohérent). Cependant, WATCH ne fonctionne pas bien avec un multiplexeur , c'est pourquoi SE.Redis vous oblige à récupérer la valeur avant la transaction , vous permettant ensuite de comparer la valeur pour affirmer qu'elle est inchangée. Même résultat ; approche légèrement différente, mais elle est sûre pour le multiplexeur. Pour en savoir plus sur ce sujet, voir ici.
