> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> I'm not sure what you were reading, but it seems pretty explicit in
Rogue
> Wave doing joins.
> ex: Inner join
> RWDBTable purchases = myDbase.table("purchase"); //1
> RWDBTable videos = myDbase.table("videos"); //2
> RWDBSelector select = myDbase.selector();
> select << purchases["orderNum"] //3
> << purchases["supplierID"] << videos["title"]; //4
> select.where(purchases["videoID"] == videos["ID"]);
>
> the myDbase.table seems pretty explicitly definining the tables.
Ah, but the important part is that from the perspective of the WHERE
clause, the joins are implicit. That is to say, the FROM clause is
never explicitly defined.
Torque can do a reasonable job of hiding the abstraction of Table from
the user. It does this already with Criterion; you simply refer to a
column as FooPeer.THECOLUMN.
A CrossDB WhereClause does not by itself contain enough information to
perform a join. That is,
List doSelect(WhereClause clause);
Is insufficient.
I thought Criteria was insufficient too, but it just has a Byzantine
syntax. Yeah, yeah, eye of the beholder, I know :-P
> And now for an outer join:
> RWDBTable employee = myDbase.table("emp");
> RWDBTable dept = myDbase.table("dept");
>
> RWDBSelector selector = myDbase.selector();
> selector << employee["empnum"] << employee["ename"]
> << employee["deptno"] << dept["deptno"] << dept["dname"];
>
> RWDBJoinExpr join = rwdbRightOuter(employee, dept); //1
> join.on(employee["deptno"] == dept["deptno"]); //2
>
> selector.from(join);
>
> Seems pretty explicit there too, no? I don't think it's possible not
to
> be explicit on how you want to join a table.
Yes, in the case of outer joins, the join is explicit. However, since
Torque is an O/R mapping framework, and outer joins do not return
objects, this syntax will never need to show up. Of course, anyone
wanting to perform outer joins outside of Torque will have to use that
syntax.
> The problem with Rogue Wave is that it's database dependent, for
example,
> doing an Oracle style join, you would not use the above way, you would
use:
> selector.where(purchase["videoID"].leftOuterJoin(videos["ID"])); //1
Yeah, looks like they took the lazy way out. I would have to inspect it
closer, but my guess is that it's possible to provide one interface and
let the pluggable database module handle the details.
> I do agree with you on the syntax for creating comparisons, that would
be
> very nice. But since it can't happen, you have to use something else.
In
> crossdb, we opted for the LESS_THAN_OR_EQUAL, but this could easily be
> changed to something like LTE which would make things look much nicer.
I'm not sure why you think this can't happen. The only real structural
change required to enable this, it seems to me, would be that columns in
CrossDB or Torque would need to be represented by an Expression object
rather than a simple String. The net result might not be as pretty as
it would be if Java supported operator overloading, but it would be a
lot prettier than the 150 methods on Criteria and the akward syntax with
constants.
Jeff Schnitzer
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
