village-2.0-dev-20021111.jar com.workingdogs.village.Record
there are posts on mailing list how to handle Records With regards, Pavel Kusch ----- Original Message ----- From: "Chris Rafuse" <[EMAIL PROTECTED]> To: "Turbine User Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, June 12, 2003 12:02 PM Subject: Re: Complex Querries with Torque > Where do I find the Record object ? What package? Its not with torque, > and I could not find it in jdbc. > > > Chris > > On Thu, 2003-06-12 at 12:23, Jeffery Painter wrote: > > Hi Chris, > > > > I would have to say after using torque for a year now, that it's > > advantages lie in data persistence and simple lookups. I know mysql does > > not offer stored procedures, however, you can always use executeQuery() > > from your peer objects to roll your own sql. This has worked for me when > > needing to run a complex query which torque just didn't offer an effective > > solution. > > > > I do believe that joins are performed at the database level though, and > > the sql generated from the torque objects can be exposed easily enough to > > see if there are problem areas. I've found the joins I've built with my > > peer classes to be quite adequate and not require me to use another > > method. > > > > You can use criteria.toString() to view the actual SQL code that will be > > sent to the database. > > > > I've heard there are some other persistence layers out there if torque > > doesn't quite meet your needs. > > > > HTH, > > Jeff Painter > > > > On 12 Jun 2003, Chris Rafuse wrote: > > > > > Hi all, > > > > > > I'm developing an application that will user Torque to manipulate a > > > MYSQL database.It will be using many of the complex SQL constructs: > > > multi table joins, complex logical conditions in the where statement, > > > summation of values, etc. Looking at the doSelectTable() methods in the > > > BaseTablePeer object of my application, I see that much of the join is > > > performed on the application side, and not on the database side. > > > > > > I need to take full advantage of the optimization of the database, so > > > this doesn't seem like a good option. Is there any other way to join > > > multiple tables with WHERE conditions then to extend the existing > > > classes? > > > > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
