db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Monroe <Greg.Mon...@dukece.com>
Subject RE: location of save() methods
Date Mon, 06 Feb 2012 14:41:59 GMT
Hmm, at first, I was OK with duplicating this in both locations.
But then I thought about some conditions I have used the stub
classes and the save function to validate or calculate field

E.g. check that fields are within a range or convert Boolean
flags to a single bit mask field.

You could still override the dbObject save method and call the 
Peer method, but you'd open a way for this safety net to be
easily accidentally bypassed by someone using the "standard" 
Peer.save() method.  Not a good feature IMHO.

I think the question here is really:

Is the save() method just an SQL action that logically belongs
in the Peer method or is it an application specific API "hook"
that should live in the dbObject world?

My vote would be for the second definition.  

Note, that you could still put it in the Peer but have it call
the dbObject method to meet this need.

-----Original Message-----
From: Thomas Fox [mailto:Thomas.Fox@seitenbau.net] 
Sent: Monday, February 06, 2012 4:22 AM
To: Apache Torque Developers List
Subject: Re: location of save() methods

Thomas Vandahl wrote:
> On 05.02.12 13:52, Thomas Fox wrote:
> > My personal opinion is that it would be more consistent if the save
> > were in the peer classes because almost all database-related operations
> > already there and it would be possible to use the dbObject objects as
> > transport objects without database functionality.
> That is going the Hibernate way, isn't it? Using beans just for data
> objects. You're about to remove a Torque-typical feature, you know.

This is why I am asking to know how people feel about this :-)
But I still think it is inconsistent. In my opinion, the row manipulating
methods should either all be in the dbObjects or in the peer (and thze
latter is more convenient because you can savely pass the objects around).
Now we have save in the dbObjects and doDelete(), doInsert() and doUpdate()
in the Peers.

> > If there are no objections, what is your preference for the default
> > behaviour ?
> I'd leave the default behavior as it is, that means generate the save()
> methods in the dbObject.
> > Shold the save methods be in the peer classes only by default or in the
> > peer and dbObject classes ?
> > what should the method name in the peer classes be ? save() or doSave
() ?
> There is already doInsert(obj) and doUpdate(obj) Do we need one more?

It is convenient not to bother whether an insert or an update is needed.
This is true independently of where the method is located. So yes, I think
the save() method is also needed in the peers if you want all row
manipulating methods in the peers.


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

DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.

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

View raw message