On 19 Jun 2011, at 1:57 PM, Thomas Fox wrote:
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.
We have needed exactly this for ages, this would be a huge help to us.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
