Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <417A462F.7060306@numerixtechnology.de>
Date: Sat, 23 Oct 2004 12:53:19 +0100
From: T E Schmitz <mailreg@numerixtechnology.de>
Reply-To: mailreg@numerixtechnology.de
User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616)
MIME-Version: 1.0
To: Apache Torque Developers List <torque-dev@db.apache.org>
Subject: Re: Torque BaseXXX in Transaction and the isNew() Method Check
References: <4172B0B9.5040300@numerixtechnology.de>
 <cl6j1c$8kf$2@tangens.hometree.net>
In-Reply-To: <cl6j1c$8kf$2@tangens.hometree.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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