Very good explanation. I will add a short summary and maybe a little
more info.
If table A contains a foreign key to B, there will be a method A.getB().
If you select an A using APeer.doSelect(crit) then a.getB() will make
another db hit to get the information for B. There are methods to join
the tables during the query. APeer.doSelectJoinB(crit) exists for this
purpose. These methods are protected to allow you to limit the public
api to those join methods that are actually useful in the app.
So
List as = APeer.doSelect(crit);
List aAndBs = APeer.doSelectJoinB(crit);
for (int i=0; i<as.size(); i++)
{
A a1 = as.get(i);
A a2 = aAndBs.get(i);
print(a1.getName() + " is related to " + a1.getB().getName());
print(a2.getName() + " is related to " + a2.getB().getName());
}
will produce the same output for both print statements. The first one
will make a db hit for every a1.getB() call. The second one will have
all the info from just one db hit.
john mcnally
Sam Solon wrote:
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
