Andrea Papotti wrote:
>>I just pass my criteria to doSelect(). It works, but I am a
>>little wary because of the JavaDoc comment at the top of
>>this method - "Old method for performing a SELECT."
>>
>
> yes, it works (or better, you dont't get exceptions), but you get only the
> columns of the peer you use, you don't get columns from other tables.
>
>
>>It would be great if the either Village code or the torque generated
>>peer code would provide a nice way of mapping from the selected
>>columns to an object you defined yourself.
>>
>
> I agree with you.
>
> bye, Andrea Papotti
>
I recently when through Torque/Turbine enlightenment so maybe I can help
clear things up -- at least as far as my current understanding goes. I'm
sure someone will correct any obvious errors.
For the following discussion, assume a table A (with fields A1 & A2) and table B
(with fields B1 & B2). Table A has a foreign key into B.
The first piece of enlightenment is that Peers wraps a table with a java
object. Although this is stated as clearly as can be in the HOW-TO it
seems to lead to two consequences.
1. The wrapped object (A.java for example) expects to have a value for
*every* field in table A when it creates the result object for a query.
Failing to do so, by explicitly using "selectColumns", results in
strange errors ("Error table has n columns" or something like that).
If you look at the generated xxxPeer code you'll see that *all* columns
are added before operations are performed.
2. This is the most important. The generated object, A.java, *only*
contains fields from table A so Peers doesn't really implement a
relational model, it implements a network model on top of a (possibly)
relational model.
In a relational model, you'd expect to issue a query and get a result.
This result table may be unlike any existing table in the database. For
example, using relational notation, "SELECT a1,a2,b2,b2 FROM A,B WHERE
a1 = b1" would result in a table with columns "a1,a2,b1,b2". But there
is no generated java object with these fields defined.
Since the selection method(s) generated (in APeer.java for example)
return a Vector of objects, there is no existing object that can be used
to wrap a result of "a1,a2,b1,b2".
In the network model that Peers creates, an accessor method "getXXXX" is
generated for tables which have foreign keys. In the example I'm talking
about, A.java will have a "getB" method declared (in reality it's in the
BaseA.java class).
This method will fetch the table B row using the foreign key and return
a B object.
Now, getting back to the question of "join" where this all started so
long ago. There are examples of how to properly perform a "join" in the
docs, and also in the mailing list archives (look for "join").
What all this almost incomprehensible (to me) code is doing is taking
the result of a join which contains all fields from both tables. It
creates a Vector of objects from the first table (the one whose xxxPeer
method was used to do the select) and then creates a reference from each
of these objects to objects it creates representing the second table.
So, as you found out, it is easy to access the first table directly, but
to access the second you have to use A.getB().b1 notation. Because you
performed a join, the B objects will already have been created and won't
require another hit on the database.
If you've followed all this, you're probably left saying "but I just
want to join two tables." Well if you've defined a foreign key between
the two, as we did above with A has a foreign key to B, then there is a
method which does the join already defined in A. It's actually in
APeers.java and is named doSelectJoinB. It's protected so to use it
you'll have to create a public method to access it.
So, to make life easy, you can create a method in APeersjava (since it
won't be overwritten if you rebuild, another whole topic in itself) such as:
public static Vector AwithB(Criteria critera) {
return doSelectJoinB(criteria);
}
The "criteria" you pass in will have all fields from both tables added
and the join criteria to match the keys from the two tables, so you
should just add whatever other selection expressions are needed.
This returns a vector of A objects and the B fields can be accessed
using the "getB" method of each of the returned "A" objects.
To make my life easier, since I use these classes as pull tools, I've
added accessor fields to make my life easier. For example in A.java
(since it won't be overwritten, unlike BaseA.java):
public String getb1() {
return getB().getb1();
}
to hide the network nature of the access.
I really should put together a complete example with code at some point
since there's probably enough handwaving in the above to leave some
people wondering about a particular point that seems clear to me.
This has probably gotten way too long and convoluted at this point but I
hope it helps at least a little.
In conclusion Peers wraps objects around tables and creates a network
access model.
There are limtations on what you can put in a Criteria object and expect
the generated code to handle.
I apologize for any inaccuracies in my understanding or presentation and
hope that someone more knowledgeable will correct them.
--
Sam Solon
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
