You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fox <Th...@seitenbau.net> on 2011/06/19 13:57:23 UTC
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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
RE: template changes to add filler methods
Posted by Greg Monroe <Gr...@dukece.com>.
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:Thomas.Fox@seitenbau.net]
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: 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
Re: template changes to add filler methods
Posted by Graham Leggett <mi...@sharp.fm>.
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: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: template changes to add filler methods
Posted by Noctarius <me...@noctarius.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Thomas,
I guess this could be achieved by using managers, won't it?
Bye, Chris
Am 21.06.2011 19:30, schrieb Thomas Vandahl:
> On 19.06.11 13:57, Thomas Fox wrote:
>> Any objections or comments to the above ? If not, I'll commit the changes
>> in a few days.
>
> If I understand the concept correctly, this is one more method to deal
> with related entities. Each of them may have its advantages and
> disadvantages, however I'm afraid it gets a bit crowded in the Peer
> classes. WDYT?
>
> One more (related) thing: Other ORM tools provide the feature that an
> object with the same primary key is actually always the same object
> instance, IOW:
>
> Book b1 = BookPeer.retrieveByPK(1);
> Book b2 = BookPeer.retrieveByPK(1);
>
> will yield b1 == b2 while Torque only achieves b1.equals(b2) Do we have
> some way to handle this? Or is this completely off?
>
> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
- --
##############################
# A Digital's Life #
##############################
Nickname: Noctarius
Location: Germany
Meet me at:
Ohloh: http://www.ohloh.net/accounts/noctarius
Web: http://www.noctarius.com
XMPP/Jabber: noctarius@jabber.ccc.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOAN/FAAoJEH/g+YBfahrqmcIP/3vjG8hFvCxVAz8ITGbn/Oxr
1bn8OW+qvnpBdiEgEVEPPmcUuj00+dJ6je54NVY6CDe+PpjlGcxs1GqompVoebV6
MVRSG3Si4FcSBarQywIurQqx07GwEXVYAG0Ly2zvt7thKn/leNiCY5a1DHnobXFz
LcdCgOnpm7Ar5823mFMY86TLzkIdXy8erxdG2+ThZ0sYWGiNMkhhc/LJHfDyrOg5
yPU9aMZYDHM9tXTc855PSlw4gLr6XPnsu59xxoz/Hq7fzY6/39tuO0t2D7t9fwXh
mombwffOM7BNKK27aX0jmZEPHbW5YQRw7xM6bnsneJ0iu1foDhPyU9DGP3J8pV+B
NVyOU1ZS7sOETIjgg1XX2gNNmprPvox9p+TP4ZO3p+sbesfQ2LiUVth5t/wjn/zl
Inj+q5WefDy2qfmPG+AZMGk2zQq+JzlnMipEClD3cikynuVYYZJKwOD3OjD33xOX
7xkHr1Y1f/qNQpoGfk6QvqE5yk6WGJBp9WhyxfaFCJymIOIW7gsLf/ld4o3mLjxR
tngu+jRjFFdurfWth69OLiI8P/+zzP6LuSjpWtSnFnRjJDU8wd8qxubk6ew+xE1t
XQZV2XlExYrZ+Sa+hl8g4jWvjpnQzNiv4/rqbS5pKTip6oT5FTSq4ShVu5xCTPF0
Nynl3bDE156NbUodisdw
=Cpw9
-----END PGP SIGNATURE-----
Re: template changes to add filler methods
Posted by Thomas Vandahl <tv...@apache.org>.
On 19.06.11 13:57, Thomas Fox wrote:
> Any objections or comments to the above ? If not, I'll commit the changes
> in a few days.
If I understand the concept correctly, this is one more method to deal
with related entities. Each of them may have its advantages and
disadvantages, however I'm afraid it gets a bit crowded in the Peer
classes. WDYT?
One more (related) thing: Other ORM tools provide the feature that an
object with the same primary key is actually always the same object
instance, IOW:
Book b1 = BookPeer.retrieveByPK(1);
Book b2 = BookPeer.retrieveByPK(1);
will yield b1 == b2 while Torque only achieves b1.equals(b2) Do we have
some way to handle this? Or is this completely off?
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org