db-torque-user 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 Mon, 27 Sep 2004 08:49:48 GMT
Good morning Henning,

Henning P. Schmiedehausen wrote:
>>What exactly do you mean by "lastState" property?
>>Do you mean a shadow object that allows youto fall back to the last 
>>saved state?
> No, no, much easier. Basically.
> <snip>
> so if you have to roll back a transaction, you can do
> myObject.setNew(myObject.isLastNew());
> And restore the "new" state of the object before a transaction. If you
> want complete rollback, then you would need a shadow object, right. I
> consider this outside the scope of Torque. 

I agree. That is really application logic whether you want to return the 
last saved state or not. Come to think about it I am not so sure anymore 
whether it makes that much sense in my application even.

>>Correct me if I am wrong but I think there is another pitfall regarding 
>>the modified flag: in doUpdate(...) the modified flag is set to false 
>>unless an exception was thrown. But as there is no feedback whether the 
>>update was actually successful it is possible for the flag to be set 
>>without the update having been carried out. (The record might've been 
>>deleted in the meantime or modified such that the criteria didn't grab 
>>the record).

This really comes down to the lack of feedback from Village, which you 
explained to me before on the dev list. If you really need to know 
whether a record has been updated you have to implement this logic in 
the application because Torque, as it is now, cannot provide the 

> Could be, yes. I've not ventured deep inside the Peer/Object logic,
> mainly because my stomach gets upset. ;-)

You must have a delicate stomach. I remember it got upset over BasePeer 
the other day. :-) (Take a look at the NullPointerException in BasePeer, 
TRQS228, and you might need a digestif.)

It takes a lot of concentration to modify the Object/Peer Velocity 
templates. The main problem is that the same Velocity code is repeated 
dozens of times to generate Java method and variable names. I don't know 
Velocity well enough to be able to judge whether, for instance, the use 
of macros could make the templates more readable.
I've made extensive changes and it took a lot of builds - not very fast 
with a growing number of tables :-(




To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message