Hi Thomas,
the situation described by you, if I got it right, is that a (payment)
module likes to avoid the rollback of a transaction in case of error.
I would try to do so by overloading methods responsible for calling that
rollback.
First thing came to my mind is to overload finalizeOrder in a
Folks,
could we please stick to English in this channel?
Cheers!
Marco
Ursprüngliche Nachricht
Von: Robert Blank
Datum: 27.11.17 17:54 (GMT+01:00)
An: dev-general@lists.oxidforge.org
Betreff: Re: Re-2: oxid V6 MySQL transactions
Hallo,
Man
Hallo,
Man kann in Doctrine leider das Rollback in verschachtelten
Transaktionen nicht feinkörnig steuern, bzw kapseln: Wenn eine der
inneren Transaktionen einen rollback macht, werden alle daran
beteiligten Transaktionen (auch die äußeren!) zurück gerollt.
Hallo,
die Antwort ist für mich wirklich schwer zu akzeptieren.
"We want really all database transactions to be rolled back, if a problem
during e.g. the payment execution occurs."
Es passiert eine payment transaktion! Wie soll auf so ein Fall korrekt reagiert
werden?
Beispiel: Eine
Hi,
in your use-case this may sound strange, but this is by design.
First by OXID eShop design:
We want really _all_ database transactions to be rolled back, if a
problem during e.g. the payment execution occurs.
Then there is the design of the underlying DBAL:
As we us Doctrine DBAL, we