La razón WATCH no está expuesto directamente debido a cómo SE.Redis está diseñado para multiplexar comandos de diferentes pilas de llamadas en una sola conexión. Esto hace que sea necesario que cualquier trabajo de transacción sea muy estrictamente administrado.
No tengo claro cuál sería el propósito de "sin cambios" por sí mismo , sin comparación con algún valor conocido; de lo contrario, solo está creando una condición de carrera. Definitivamente sería posible agregar soporte para él, pero realmente me gustaría entender primero el caso de uso esperado. ¿Puedes explicarlo?
Re su edición; su ejemplo preferido (el último) simplemente no es posible con redis - nada que ver con SE.Redis; si haces un GET dentro de un MULTI , no obtiene la respuesta hasta el EXEC se completa, por lo que posiblemente no pueda usar el valor en el SET :todavía no está disponible .
Si no fuera por la multiplexación, podría reordenar un poco su segundo ejemplo (según lo que hace SE.Redis):
WATCH key
val = GET key
MULTI
val = val + 1
SET key $val
EXEC
este es el típico uso de WATCH :tú miras las cosas que está consultando de antemano, entonces sabe que {key} permanece sin cambios durante este ciclo (o al menos, la transacción se habrá abortado; no hay estado inconsistente). Sin embargo, WATCH no funciona bien con un multiplexor , razón por la cual SE.Redis lo obliga a seguir la ruta de obtener el valor antes de la transacción , y luego le permite comparar el valor para afirmar que no ha cambiado. Mismo resultado; enfoque ligeramente diferente, pero es seguro para el multiplexor. Para obtener más información sobre ese tema, consulte aquí.
