db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Monroe <Greg.Mon...@dukece.com>
Subject RE: created torque 4 branch with village removed
Date Mon, 01 Nov 2010 13:39:41 GMT
Great work

Re: Prepared statements..

+1 on making all calls via prepared. As said, helps with SQL injection and probably improves
performance for most use cases.  One possible headache might be the CUSTOM.SQL 

Question:  Can we still do generic record queries or is this limited to only Torque table
records?  E.g., generate "Select t1.col1, t2.col1, ... from t1, t2 where..." using Criteria,
then call something similar to BasePeer.doSelect(c) and process the results.  I know this
has been a common answer to "Can torque do this..." queries in the past.

> -----Original Message-----
> From: Thomas Fox [mailto:Thomas.Fox@seitenbau.net]
> Sent: Sunday, October 31, 2010 5:22 PM
> To: Apache Torque Developers List
> Subject: Re: created torque 4 branch with village removed
> > >> - check whether to revive the doPsSelect methods or whether all
> selects
> > > can
> > >> use prepared statements
> > >
> > > Re-added BasePeer.doPSSelect() for now.
> >
> > This method has some weaknesses IIRC. It dos not work correctly with
> > selects containing joins. I'd prefer to use prepared statements for all
> > selects if at all possible and I don't think we need separate methods.
> So would I. Much less room for SQL-injection attacks. Will take a bit of
> work, but if nobody objects, I'll have a go at it.
> > >> - there was come code in doDelete which handled cascading deletes
> (at
> > > leats
> > >> theoretically, never saw it working) tris needs to be reimplemented
> > >
> > > Not re-added. The code can definitely not have worked for composite
> foreign
> > > keys because there is no way to tell a composite foreign key from the
> > > database map.
> >
> > Still I'm pretty sure that deletes containing joins do not work
> > correctly. So there should be another solution some day.
> What do you mean by "deletes containing joins"? A delete which where
> clause
> contains a join or a delete which deletes from multiple tables? I'm
> pretty
> sure the former works now as the table name is now specified in the
> interface (no magic table-to-delete-from detection from the criteria any
> more); not sure whether the latter can work in SQL.
> Would you mind to create a simple test case to show what you mean ?
> > >> - Maybe one can clean up LargeSelect from the reflection stuff
> therein
> > >
> > > Not while the Peers have static methods.
> > >> ...
> >
> > I beg to differ. LargeSelect just tries to call the methods
> > addSelectColumns() and populateObject() on the given builder class. You
> > can provide any class you want here. I'd prefer to use some kind of
> > Builder-interface for this, however.
> Agreed. But does one not still need to have non-static methods for
> implementing an interface.
>    Thomas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org

DukeCE Privacy Statement:
Please be advised that this e-mail and any files transmitted with
it are confidential communication or may otherwise be privileged or
confidential and are intended solely for the individual or entity
to whom they are addressed. If you are not the intended recipient
you may not rely on the contents of this email or any attachments,
and we ask that you please not read, copy or retransmit this
communication, but reply to the sender and destroy the email, its
contents, and all copies thereof immediately. Any unauthorized
dissemination, distribution or copying of this communication is
strictly prohibited.

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message