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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to