Transacciones
Leyendo el resultado
For everything you offer
to a data holder, the offer
method will yield a DataTransactionResult. This
object will contain the following:
Tipo
El :javadoc: DataTransactionResult.Type indica si la transacción se completó con éxito y, de no ser así, cómo falló.
“” INDEFINIDO “” |
Ningún resultado claro para la transacción - indica que algo salió mal |
“” ÉXITO “” |
La transacción se completó exitosamente |
`` FALLO`` |
Transacción fallida por motivos esperados (por ejemplo, datos incompatibles) |
“” ERROR”” |
Transacción fallida por razones inesperadas |
“” CANCELADO “” |
Un evento para esta transacción fue cancelado |
Los datos afectados
El resultado también provee un par de listas inmutables con contenedores de valor inmutables que representan los datos que estuvieron involucrados en la transacción.
|
|
|
|
|
Ejemplos
Sanando a un jugador
Seguramente recuerdas el ejemplo de curación en la página :doc: keys. Imagina que un jugador que tiene menos de la mitad de un corazón (lo que equivale a 1 salud) se cura de esa manera. El DataTransactionResult
en ese caso se vería así:
`` getType () `` devolvería `` SUCCESS``
`` getRejectedData () `` sería una lista vacía
`` getReplacedData () `` contendría un contenedor de valores para la clave `` Keys.HEALTH`` con un valor de 1.0
getSuccessfulData () contendría un contenedor de valor para la clave Keys.HEALTH` con un valor de 20.0
Now what would be different if we used the healing example from the Datos Personalizados page instead? Since the
HealthData
data manipulator contains values for both the current and the maximum health, in addition to the
above result, both the getReplacedData()
list and the getSuccessfulData()
list would contain one more element:
A value container for the Keys.MAX_HEALTH
key with a value of 20.0.
Ofreciendo HealthData a un bloque de piedra
Ahora nuestros ejemplos mencionados anteriormente están codificados de tal manera que fallarán en lugar de tratar de ofrecer los datos incompatibles. Pero imagina que tomamos un `` HealthData`` de un jugador (completamente sanado) e intentamos ofrecerlo al :javadoc: Location del bloque de piedra en el que se encuentra actualmente. Podemos hacer esto, ya que `` Location`` también es un soporte de datos. Y si lo hacemos, nos recompensaría con un `` DataTransactionResult`` como este:
`` getType () `` devolvería `` FAILURE``
`` getRejectedData () `` contendría dos contenedores de valores para las claves `` HEALTH`` y `` MAX_HEALTH``, cada una con un valor de 20.0
`` getReplacedData () `` y `` getSuccessfulData () `` serían listas vacías
Revertir transacciones
Como todo sobre un resultado de transacción es inmutable, puede servir para la documentación de cambios de datos. Y también permite deshacer esos cambios en los documentos. Para eso, simplemente pase el resultado de la transacción por el método `` undo () `` del titular de los datos. Esto es particularmente útil desde que algunas ofertas de datos pueden ser parcialmente exitosas, por ello uno o más valores se escriben exitosamente en el titular de los datos, sin embargo, no se puede aceptar un valor más. Dado que es posible que desee deshacer los éxitos parciales.
** Ejemplo de código: revertir una transacción **
import org.spongepowered.api.data.DataHolder;
import org.spongepowered.api.data.DataTransactionResult;
import org.spongepowered.api.data.manipulator.DataManipulator;
public void safeOffer(DataHolder target, DataManipulator data) {
DataTransactionResult result = target.offer(data);
if (result.getType() != DataTransactionResult.Type.SUCCESS) {
target.undo(result);
}
}