Re: Fwd: Re: Re-2: oxid V6 MySQL transactions

2017-11-27 Thread Keywan Ghadami
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

Re: Re-2: oxid V6 MySQL transactions

2017-11-27 Thread Marco Steinhaeuser
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

Re: Re-2: oxid V6 MySQL transactions

2017-11-27 Thread Robert Blank
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.

Re-2: oxid V6 MySQL transactions

2017-11-27 Thread oxid mailinglist
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

Re: oxid V6 MySQL transactions

2017-11-27 Thread Robert Blank
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