db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lin <xuhua....@gmail.com>
Subject Re: save an object tree / bug concerning the MODIFIED-flag
Date Wed, 15 Sep 2004 19:52:56 GMT
Hi,  Daniel, so basically setting "torque.addSaveMethod = true" solved
your original 2 problems. That's good to know.

I understand your point that object fresh from DB should not be marked
as modified. But this will depend on the usage of API.(This flag is
set to true by default when object created.)  My understanding is that
Torque provides 2 ways to do an update:
 (1) through Object.save();
 (2) through Peer.doUpdate(Object) or Peer.doUpdate(Criteria).
The first method is an instance method and it checks modified flag,
hence making object more intelligent. I think this is why Peer.vm
adding setModified(false) for Object.save only. The second method is a
static one and it doesn't check modified flag since it assumes user of
this API will know when to call this function to do a real
update.(What's the use case when getting an object from DB, doing
nothing, and immediately calling a doUpdate?)
Certainly doUpdate can be easily changed to check modified flag  on
the object passed in (and Peer.vm adding setModified(false)  for all
object fresh from DB), but this functionality already in the first

I think Torque is different from DAO pattern. Since it solves real
problems nicely and easily, I don't see the need to change it to fit
any pattern.


On Wed, 15 Sep 2004 09:19:23 +0200, Vitzethum, Daniel
<daniel.vitzethum@gigatronik.com> wrote:
> Hello,
> and thank you for your numerous answers. I have to admit that
> my first mail was a little bit unprecise in some points, so
> I'm trying to get this right. Perhaps I should notice that I'm
> quite new to Torque, bot not to O/R mapping...
> My problem in general, the saving of an object tree, is solved
> by generating the save methods, as I had generated my OM classes
> with option
>  "torque.addSaveMethod = false"!
> I just don't like the idea of TOs having logic in them. I would
> prefer dumb beans as TOs and smart DAOs aka Peers. Is there any
> way in Torque of getting my code generated in that way (I guess
> there is no way...) - or in other words: can Torque fit the DAO
> pattern?
> Yesterday, after having written my mail, I noticed that, in the
> Peer.vm template, the code for the modified flag is not written
> in that case:
>  Peer.vm:
>   #if ($addSaveMethod)
>     obj.setModified(false);
>   #end
> I don't understand the relation between generating the save methods
> and _not_ setting the modifed flag to false for a fresh row from DB
> in that case.
> Also, when addSaveMethod option is set to true, the saving of
> the object tree is implemented in the save method of each object,
> e.g. BaseBook.
> @Howard:
> > For your second question, I don't think it's a bug. I think Torque
> > assumes you are going to do something with the object, otherwise you
> > can always call setModified(false) before call save.
> I don't think that this is right, at least  from a idealistic point of
> view. A row that is fresh from DB _is_ not modified. Why setting the
> flag to "true" just for the case?  In my opinion, every setter method,
> e.g. book.setName(), should set the modified flag to true when used.
> The problem with unwanted updates is that there may be a DB trigger that
> will be fired onUpdate - even when there is nothing to update...
> Greetings, and thanks for your help again,
> Daniel
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org

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

View raw message