En realidad, así es exactamente como Transacciones anidadas fue diseñado para. Cito de documentos de Oracle:
Entonces, una transacción secundaria en una transacción anidada regular no tiene voz con respecto a cómo él o los otros niños o padres (transacción más grande ) podría comportarse, aparte de cambiar datos mutuos o fallar por una excepción.
Pero puede otorgarle (transacción secundaria ) una posibilidad de voto muy limitada en su destino utilizando la sub-transaction característica como se indica en los rieles docs
pasando requires_new: true
User.transaction do
User.create(username: 'Kotori')
User.transaction(requires_new: true) do
User.create(username: 'Nemu')
raise ActiveRecord::Rollback
end
end
Que como dicen los documentos:solo crea 'Kotori'. ya que el poderoso niño 'Nemu' eligió morir en silencio.
Más detalles sobre las reglas de transacciones anidadas (documentos de Oracle )
Actualización:
Para comprender mejor por qué los rieles nested transactions funciona de esta manera, necesita saber un poco más sobre cómo funcionan las transacciones anidadas en el nivel de base de datos, cito de documentos api de Rails
:
Ok, entonces los documentos describen el comportamiento de una nested transaction en los dos casos mencionados de la siguiente manera:
En caso de una llamada anidada, #transaction se comportará de la siguiente manera:
-
El bloque se ejecutará sin hacer nada. Todas las declaraciones de la base de datos que ocurren dentro del bloque se agregan efectivamente a la transacción de la base de datos ya abierta.
-
Sin embargo, si se establece :requires_new, el bloque se incluirá en un punto de guardado de la base de datos que actuará como una subtransacción.
Me imagino cuidado, solo imagina que:
opción(1) (sin require_new) está ahí en caso de que haya usado un DBMS que sea totalmente compatible con nested transactions o está satisfecho con el comportamiento "falso" de nested_attributes
mientras opción(2) es admitir el savepoint solución alternativa si no lo hace.
