db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From T E Schmitz <mail...@numerixtechnology.de>
Subject Re: Torque BaseXXX in Transaction and the isNew() Method Check
Date Sat, 23 Oct 2004 11:53:19 GMT
Hello Henning,
I see you are spending your Saturday morning on Torque ;-)


Henning P. Schmiedehausen wrote:

> T E Schmitz <mailreg@numerixtechnology.de> 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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message