Il motivo WATCH non è esposto direttamente è a causa del modo in cui SE.Redis è progettato per multiplexare comandi da diversi stack di chiamate su una singola connessione. Ciò rende necessario che qualsiasi operazione di transazione sia molto strettamente gestito.
Non sono chiaro quale sarebbe lo scopo di "non modificato" di per sé , senza confronto con un valore noto, altrimenti stai solo creando una condizione di gara. Sarebbe sicuramente possibile aggiungere il supporto per questo, ma mi piacerebbe davvero capire prima il caso d'uso previsto. Puoi spiegare?
Re la tua modifica; il tuo esempio preferito (l'ultimo) semplicemente non è possibile con redis - nulla a che vedere con SE.Redis; se fai un GET all'interno di un MULTI , non ottieni la risposta fino a EXEC completes - quindi non è possibile utilizzare il valore nel SET :non è ancora disponibile .
Se non fosse per il multiplexing, potresti riordinare un po' il tuo secondo esempio (in base a ciò che fa SE.Redis):
WATCH key
val = GET key
MULTI
val = val + 1
SET key $val
EXEC
questo è il tipico uso di WATCH :tu guarda le cose che stai interrogando in anticipo, allora sai che {key} è invariato durante questo ciclo (o almeno, la transazione sarà interrotta; nessuno stato incoerente). Tuttavia, WATCH non funziona bene con un multiplexer , ecco perché SE.Redis ti obbliga a recuperare il valore prima della transazione , consentendo quindi di confrontare il valore per affermare che è invariato. Stesso risultato; approccio leggermente diverso, ma è sicuro per multiplexer. Per ulteriori informazioni su questo argomento, vedere qui.
