Moving methods to generated / changing interface +1 from me. Get/SetByName, et. al.
IMHO, we need to have an interface that covers these. A use case for this would be common normalization or lookup functions. E.g., a function with a record object and column name as parameters that does something common to multiple table and columns, like scanning for profanity or normalizing case in across multiple tables that contains title and description fields. Perhaps this could be based on the java LinkedHashMap object methods or the org.apache.commons.collections.OrderedMap interface? With the key being the column name. Then allow users the choice of simple persistent objects or collection based persistent objects (which is a superset of the simple objects). I think you're right about getTableMap. That is Torque specific (but needed). If someone needs it inside a function using an interface parameter, they can always cast the object to get to it. -----Original Message----- From: Thomas Fox (JIRA) [mailto:[email protected]] Sent: Saturday, July 30, 2011 4:34 PM To: [email protected] Subject: [jira] [Commented] (TORQUE-147) Database objects should not need to inherit from BaseObject [ https://issues.apache.org/jira/browse/TORQUE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073242#comment-13073242 ] Thomas Fox commented on TORQUE-147: ----------------------------------- I plan to impelemt this as follows: - move the isNew and modified flags (incl getters and setters) from BaseObject to the generated base classes - move the hashCode and equals methods from BaseObject to the generated base classes - remove the class BaseObject from the runtime - make all classes implement the org.apache.torque.om.Persistent interface This makes all test cases green. The following methods from BaseObject are not moved currently: - get/setByName, get/setByPeerName, get/setByPosition: I would not define those as necessary for persistent objects. Maybe these methods can be moved to a different interface which is only implemented if the user choses to generate these methods ? - getTableMap: Nots sure what to do with this method, if this were moved to the persistent interface it would make the interface rather Torque-specific. Currently it is not needed that the Persistent interface defines this method, and I'd rather leave this as is. The following methods are already implemented/overridden: - the save(...) methods which are defined in persistent are already generated - the getters/setters for the primary key which are defined in BaseObject are overridden in the generated classes. However, to retain current catch clauses in the generated classes, I'd change the throws clauses in persistent from Exception to TorqueException, plus these methods need also be implemented (throwing UnsupportedOperationExceptions) for tables without primary key. > Database objects should not need to inherit from BaseObject > ----------------------------------------------------------- > > Key: TORQUE-147 > URL: https://issues.apache.org/jira/browse/TORQUE-147 > Project: Torque > Issue Type: Improvement > Reporter: Thomas Fox > Assignee: Thomas Fox > > Currently it is an error if database objects do not inherit from BaseObject. > This makes embedding of Torque objects in other frameworks very difficult, > because it does not allow to choose an own parent to inherit from. > The minimum requirement would be that it is not required any more that > database objects inherit from BaseObject. > Ideally BaseObject dies and the base objects inherit directly from > java.lang.object. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- 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.
