Armin Waibel wrote:
Hi,
there was no response to my previous post, thus I checked in the changes
described in the previous post.
Vadim, if you have unit test using stored procedures please run these
tests against CVS OJB_1_0_RELEASE.
Is it correct that methods like PB.getByIdentity(Identity) never using
(Do you mean getObjectByIdentity()?)
stored procedure?
No, this statement is not correct. getObjectByIdentity uses
StatementManager.getSelectByPKStatement, and this can return SelectByPKProcedure.
In method JdbcAccessImpl#materializeObject I always
use a "normal" query - is this correct?
No, it can be stored procedure.
To detect a stored procedure a sql-String based detection method was
used - JdbcAccessImpl#isStoredProcedure(String sql). Did my best to
implement it as efficient as possible to reduce the performance impact.
Looks good.
Sorry for late reply,
Thanks,
Vadim
regards,
Armin
Armin Waibel wrote:
Hi all,
I patched PlatformSapdbImpl to support #isCallableStatement in a correct
manner. But it's crap, because the patch have to access two non-public
fields in two sap-driver classes, thus I don't know if older or future
versions of the jdbc-driver will work with this patch.
So I recommend to introduce an contract between StatementManagerIF and
JdbcAccessImpl to specify what kind of statement is used (as Vadim point
out currently there is none) by changing StatementsForClassIF and
StatementManagerIF. To support OJB-31 and OJB-6 these pluggable
components are already changed (compare with OJB 1.0.3).
To decide if a CallableStatement is needed or not in JdbcAccessImpl
the sql-query String will be evaluated (this isn't a smart solution,
but it won't be costly).
With these changes Platform#isCallableStatement is no longer needed
(and all problems with maxDB/sapDB are solved).
regards,
Armin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
