Return-Path: <a7b46501@telus.net>
Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Delivered-To: mailing list torque-user@db.apache.org
Received: (qmail 82403 invoked from network); 2 Jul 2003 03:37:22 -0000
Received: from outbound05.telus.net (HELO priv-edtnes43.telusplanet.net)
 (199.185.220.224)
  by daedalus.apache.org with SMTP; 2 Jul 2003 03:37:22 -0000
Received: from localhost ([199.185.220.240])
          by priv-edtnes43.telusplanet.net
          (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP
          id <20030702033731.DRQX2081.priv-edtnes43.telusplanet.net@localhost>
          for <torque-user@db.apache.org>; Tue, 1 Jul 2003 21:37:31 -0600
Received: from 204.62.206.252 ( [204.62.206.252])
	as user a7b46501@192.168.200.1 by webmail.telus.net with HTTP;
	Tue,  1 Jul 2003 20:37:31 -0700
Message-ID: <1057117051.3f02537bb20b8@webmail.telus.net>
Date: Tue,  1 Jul 2003 20:37:31 -0700
From: a7b46501@telus.net
To: Turbine Torque Users List <torque-user@db.apache.org>
Subject: Re: question on Torque's limitation
References: <1057081273.3f01c7b9625b7@webmail.telus.net>
In-Reply-To: <1057081273.3f01c7b9625b7@webmail.telus.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.1-cvs
X-Originating-IP: 204.62.206.252
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Well, I am a little amused to find my original post generated so many 
feedbacks. After ignoring those anti-MS defenses and empty OM babble which 
have no contribution to the issue at hand, my conclusion is still unchanged: 
that CURRENT Torque 3.0 cannot provide added-value support for ad hoc query 
simply because there is no object modeling for ad hoc query at all. This can 
be demonstrated in the Torque xml schma dtd at
http://jakarta.apache.org/turbine/dtd/database.dtd:
<!ELEMENT database (table+)>
You can see the ONLY database entity Torque can model is a table. 
Surprisingly, I found building Torque OM out of ad hoc query isn't that a 
challange. All it requires is being able to support following schma xml:
<!ELEMENT database (table+,query+)>
Here "query" element is used to build an ad hoc query. An example would be:
<query>
  <select>
    <field name="name" type="varchar" formular="nvl(T2.name,T1.name)">
    <field name="id" type="integer" formular="T1.id">
  </select>
  <from>
    <table name="A" alias="T1">
    <table name="A_TR" alias="T2">
  </from>
  <where>
    ...
  </where>
  <orderby>
    ...
  </orderby>
</query>

In fact <query> element is easier to implement than <table> because you don't 
need to generate sql out of it and you don't need to worry about pk-fk 
relations with other entities. All it requires for an OM is to parse to a SQL 
statement and "fill" out the data at runtime. It can even be extended easily 
to support parametrized query. Note that in the formular attribute you can 
write any SQL statement that is supported by the underlining DBMS (I use 
Oracle nvl as illustration). This defies Java's philosophy: rather than 
scaling down to most-common denominator, delegate to the underlying layer 
instead.
The only difficulty I can foresee is to support wild card query. But to start 
with, it's not a big deal to omit it.

That's my idea so far. As a side note, for those who don't familiar with .Net 
and doubt its cross vendor support, it is also built to support multiple DBMS 
like Torque. I runs it on an Oracle server w/o any problem.

Fred

Quoting a7b46501@telus.net:

> This is not a matter of how one thinks. It's a matter of can or cannot, and
> to what degree of easiness and efficiency.
> If Torque's OM can solve the issue I stated without multiple db hits for
> performance's sake, I wouldn't mind to think in terms of OM. But if OM
> cannot match the flexibility of SQL, which is what Torque is trying to
> replace as API, then it is fruitless no matter how hard you think in
> Torque's way. Torque OM simply cannot live up to such a modest expectation.
> In fact, I would be open to another OM tool, lest to say breaking Torque's
> OM.
> From my investigation, Torque's limitation is molded in its design.
> Torque's
> OM is built out of a Table of a database. Comparing with Microsoft's .Net's
> dataset OM, which can be built out of an ad hoc query and modified at
> design
> time in the format of XML, the technology lag of Torque is apparent.
> 
> Fred
> 
> ----- Original Message -----
> From: "Mark Lowe" <mark.lowe@talk21.com>
> To: "Turbine Torque Users List" <torque-user@db.apache.org>
> Sent: Tuesday, July 01, 2003 6:39 AM
> Subject: Re: question on Torque's limitation
> 
> 
> > I'm also pretty new to torque but resorting to SQL breaks the model..
> >
> > My understanding is that you should have to think in terms of SQL but
> > in terms of the object model, which is the whole point. I'll have a
> > look over the documentation, but I'd be very disappointed if it was the
> > case that you'd have to do this. From what I've seen so far the api
> > would only be more complex than it needs if you're still thinking in
> > SQL rather than Objects.
> >
> > My money is on all this being possible without breaking any design
> > patterns (e.g. resorting to sql). I'll drop another posting when I've
> > taken a look and can be more helpful.
> >
> > Cheers mark
> >
> > On Tuesday, Jul 1, 2003, at 09:34 Europe/London, Sam Le Berrigaud wrote:
> >
> > > Hello,
> > >
> > > I am also quite new to Torque. But what I think I would is not use
> > > Criteria to do so, I would rather use the executeQuery method in which
> > > you can write your own SQL with no problem. Maybe you could also try
> > > to write your own criteria as shown in criteria how-to in the section
> > > simplifying Criteria.
> > >
> > > Regards,
> > >
> > > SaM
> > >
> > > a7b46501@telus.net wrote:
> > >
> > >> Suppose I have an Oracle table called A and a table called A_TR (TR
> > >> stands for translation) for multi-language support. These two tables
> > >> contain following columns respectively:
> > >> A.ID (pk), A.NAME
> > >> A_TR.ID(pk, fk to A.ID), A_TR.LOCALE (pk), A_TR.NAME
> > >>
> > >> If I want to get A_TR.NAME if it is available, othwise use A.NAME.
> > >> Using SQL, I can get it pretty easily:
> > >> select nvl(A_TR.name,A.name) as name from A, A_TR where
> > >> A.id=A_TR.id(+) and lower(A_TR.locale(+)) = lower('en-us')
> > >>
> > >> But it seems in Torque this will be awefully complex if not
> > >> impossible (unless I resort back to brute force SQL). The
> > >> complication arises from:
> > >> 1. Creteria doesn't support outer-join
> > >> 2. The peer class doesn't support ad hoc SELECT clause. I can only
> > >> get the columns within a table. Combining columns in two tables with
> > >> Oracle function such as NVL is almost impossible.
> > >>
> > >> Since I am new to Torque, I would like confirmation if these indeed
> > >> are limitation of Torque. Is there any get-around that doesn't need
> > >> multiple db hit (don't take query cache into account)?
> > >>
> > >> Thanks
> > >>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > >> For additional commands, e-mail: torque-user-help@db.apache.org
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > For additional commands, e-mail: torque-user-help@db.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-user-help@db.apache.org
> >
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
> 
>