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 values.
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:[email protected]] 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 methods > > were in the peer classes because almost all database-related operations are > > already there and it would be possible to use the dbObject objects as pure > > 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. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
