I'm +1 on the concept... but like Thomas V wonder about too much loaded into the Peer class. At first, I was going to suggest making it into a "Helper" class, like the SummaryHelper or LargeSelect, but on reflection, that might not be easy to do as you can in the generated Peer class. It definitely would have to use the Map classes and maybe a bit of class reflection.
Hmm, I wonder if this could be tucked into the "doSelect" methods as an extra flag parameter. E.g., if you do something like: boolean fillRelated = true; AuthorPeer.doSelect(criteria, true); Then a variation of your fill method gets called to efficiently return fully populated objects. Another thought is that the fillRelated flag might be added to the Criteria object since it would be similar to the setUseTransaction() method. Just some quick thoughts... But I could be convinced of just going with the fillXXX method if the JavaDocs made it very clear about what it was. Greg -----Original Message----- From: Thomas Fox [mailto:[email protected]] Sent: Sunday, June 19, 2011 7:57 AM To: Apache Torque Developers List Subject: template changes to add filler methods I have locally implemented filler methods for associated objects and would like to commit the changes. The filler methods efficiently read related objects. E.g. for the author and book tables in the tutorial, the generated methods are AuthorPeer.fillBook(Collection<Author>) and BookPeer.fillAuthors (Collection<Book>), and they fill the collBooks field of each author in the passed list and the aAuthor field of each book in the list. The generated filler methods collect the relevant local keys from the objects in the passed list and retrieve the associated objects for chunks (of configurable size) of the keys. A sample query would be SELECT * FROM BOOK WHERE AUTHOR_ID in (${authorId1},${authorId2}, ...). This is a very fast method of loading related objects for a list of objects (fewer query than lazy loading, less duplicate data transferred than joins). The methods will return lists of the retrieved objects (e.g. AuthorPeer.fillBook(Collection<Author>) returns a list of authors) so cascaded filling is possible. The generated methods also work for composite foreign keys and for foreign keys which do not reference the primary key of the referenced table. To re-use the exising selectByPrimaryKeys() methods, I have added methods to the object which return the foreign key for accociated objects as ObjectKey. E.g. the Book object has the method ObjectKey getForeignKeyForAuthor(). The generation of the filler methods can be switched off by a generation option. Currently the default is that the filler methods are generated. I have also written test cases for the filler methods. I have added a new schema to the test project which contains possible foreign-key relations in a systematic manner. The goal would be to migrate existing test tables and tests which also test foreign keys to this schema The filler tests are in a new package, org.apache.torque.generated.peer, with the idea to split the current DataTest class into smaller test classes for one function type each (e.g. testDoDelete, testDoSelect etc). Any objections or comments to the above ? If not, I'll commit the changes in a few days. 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]
