Hello Henning, I see you are spending your Saturday morning on Torque ;-)
Henning P. Schmiedehausen wrote:
T E Schmitz <[EMAIL PROTECTED]> writes:
I would like to add a few notes to the transaction/rollback discussion which we had a few weeks back. To handle a rollback situation just resetting the isNew flag isn't enough. The other thing that is changed after a successful INSERT are the primary key properties. If you use SEQUENCEs the PK columns are null prior to save and the are populated by doInsert(). Only upon successful completion of the transaction can the new flag and PKs be set!
If I remember our discussion correctly, we were talking about veto'ing the insert/update before anything actually hits the database / in a rollback situation. Once something had actually hit the DB and changed the state, then yes, you are correct. Torque does not handle this case and I don't see any simple way to do so.
I was thinking much too complicated there. My apologies.
What I am needing to achieve is quite simple and it can indeed be solved with a second flag:
a) I use transactions and an object, which was inserted during T1 might be re-used for a second attempt in transaction T2.
b) An object inserted in T1 might be updated later within the same transaction.
a) requires the object to be re-inserted in T2. b) the object needs to be updated; might seem senseless but I have such a case.
The Primary Keys don't pose a problem for Torque. In example a) a new SEQUENCE number is assigned automatically (if using autincrement). As long as the application doesn't use the PK after T1, the situation can simply be handled with a second flag.
The only solution I could see to handle the above situations: - boolean isUncommitted; - upon object creation: isUncommitted=isNew(); - after commit: isUncommitted=false; - after reset: setNew(isUncommitted);
I also keep a 2nd isModified flag so I can reset it to its state before the save() operation.
The question is whether this logic should be provided in Object.vm. I am currently handling this in a wrapper object, which has a commit() and reset() method, but I guess the additional flag[s] could be placed in Object.vm.
However, for this to work, anyone using transactions would have to explicitly set the flag after commit/rollback.
==============
I don't remember whether an issue has been created for this on Scarab? I think the introduction of a 2nd flag is unavoidable to support transaction logic.
BTW, I much appreciate that you're tackling so many issues now. Makes it feel worthwhile spending time on Torque, filing bug reports etc.
--
Regards/Gru�,
Tarlika
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
