RE: created torque 4 branch with village removed

[Greg Monroe <Gr...@dukece.com>]

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

RE: created torque 4 branch with village removed

[Thomas Fox <Th...@seitenbau.net>]

> 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.

Yes, one can. There is the org.apache.torque.om.mapper.ObjectListMapper
which will return a List of object lists. Either one can tell the Mapper
which classes should be used for the columns (database independent), or one
can let the db driver decide if one does not care about database
independence. See e.g. the
org.apache.torque.util.SummaryHelperTest.testSummarize() method in the test
project for an example.

   Thomas


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