db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Vandahl <thomas.vand...@tewisoft.de>
Subject Re: BasePeer.doPSSelect with complex query fails.
Date Tue, 15 Mar 2005 15:53:57 GMT
Hi Thomas,

Thomas Fischer wrote:
> I could verify that a doPSSelect throws an error on joins where a DoSelect
[...]
> Are we talking about the same error ? I would guess not. Probably you are
> not using CVS HEAD; there have been quite allot changes in the meantime,
> especially regarding joins....
No we aren't. My criteria contains select columns. Actually in the 
QueryDataSet(ResultSet) constructor populates the internal schema object 
from the resultset meta data. This sets isSingleTable internally to false.
If I now call fetchRecords() I get the said DataSetException which is 
thrown by schema().tableName() if isSingleTable is false.

> Also, are you sure that doPSSelect reuses its statements (i.e. does it
> really boost performance)? I am asking because doSelect() also uses
> prepared statements to executeSQL, however, it throws away the prepared
> statement instead of re-using it. From my glance into the Code of
> doPSSelect in CVS HEAD, the prepared statement gets thrown away just as in
> doSelect(). I have also looked into 3.1.0 code, same thing there.
Well, this needs to be tested. From what I see in the DBCP code, 
prepared statements should be pooled per connection. There is also some 
caching stuff going on in the JDBC layer. Because of the problem above I 
could not verify how this really works.

> This should definitely make its way into scarab. I am just not sure about
> the action to take. In my opinion, one should call doSelect within
> doPSSelect(), and deprecate the doPSSelect() methods, as they do not add
> any functionality in my opinion.
> As to re-using the prepared statement, this could also be done within
> doSelect(). However, this would mean to replace village (how often did I
> already write these words ???), which is not an easy task. Also, if the
> statement is cached, appropriate action must be taken that the cache is
> emptied if the criteria is modified in any way. This is also a lot of work.
 From my point of view this is more or less a problem of connection 
pooling in servlet applications. I vote for throwing away the PS methods 
as they are now. This needs a fresh start.

Bye, Thomas.


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


Mime
View raw message