Return-Path: Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm Delivered-To: mailing list torque-user@db.apache.org Received: (qmail 66730 invoked from network); 1 Jul 2003 20:00:54 -0000 Received: from tmailt1.svr.pol.co.uk (195.92.137.107) by daedalus.apache.org with SMTP; 1 Jul 2003 20:00:54 -0000 Received: from user-1710.bbd15tcl.dsl.pol.co.uk ([81.77.182.174] helo=talk21.com) by tmailt1.svr.pol.co.uk with esmtp (Exim 4.14) id 19XRJC-0003hF-Nk for torque-user@db.apache.org; Tue, 01 Jul 2003 21:00:58 +0100 Date: Tue, 1 Jul 2003 21:00:57 +0100 Subject: Re: question on Torque's limitation Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Mark Lowe To: "Turbine Torque Users List" Content-Transfer-Encoding: 7bit In-Reply-To: <1057081273.3f01c7b9625b7@webmail.telus.net> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tuesday, Jul 1, 2003, at 18:41 Europe/London, a7b46501@telus.net wrote: > This is not a matter of how one thinks. That's simply not true.. else we wouldn't be using java now would we.. And i maintain that you mode of thought is effecting the solutions that you CAN'T seem to find. > It's a matter of can or cannot, and > to what degree of easiness and efficiency. That would depend how easy wouldn't it.. And what or who CAN'T and can.. > 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 I'm not even going to answer that.. Now I understand what the problem is.. I'm sure all the folks who develop torque are really happy about you generous feedback... > 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" > To: "Turbine Torque Users List" > 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 >