This one time, at band camp, Mickael Guessant said:
MG>When debugging Castor mapping file, the SQL statements issued by Castor
MG>can be incorrect. As everything is hidden in the internals of the
MG>library, it can get tricky to determine what is wrong.
MG>
MG>In such cases, having the SQL statement in the log just before the
MG>exception can really help...
MG>
MG>Here is the patch to SQLEngine to get those logs :
MG>
MG>src/main/org/exolab/castor/jdo/engine/SQLEngine.java
MG>627a628,629
MG>> if ( _logInterceptor != null )
MG>> _logInterceptor.storeStatement( "Error creating " + _type + ",
MG>SQL : " + _sqlCreate );
MG>760a763
MG>> String storeStatement = null;
MG>770c773,774
MG>< stmt = ( (Connection) conn ).prepareStatement(
MG>getStoreStatement(
MG>original ) );
MG>---
MG>> storeStatement = getStoreStatement( original );
MG>> stmt = ( (Connection) conn ).prepareStatement( storeStatement );
MG>876a881,882
MG>> if ( _logInterceptor != null )
MG>> _logInterceptor.storeStatement( "Error updating " + _type + ",
MG>SQL : " + storeStatement );
MG>920a927,928
MG>> if ( _logInterceptor != null )
MG>> _logInterceptor.storeStatement( "Error deleting " + _type + ",
MG>SQL : " + _sqlRemove );
MG>1080a1089,1090
MG>> if ( _logInterceptor != null )
MG>> _logInterceptor.storeStatement( "Error loading " + _type + ",
MG>SQL : " + (( accessMode == AccessMode.DbLocked ) ? _sqlLoadLock :
MG>_sqlLoad) );
Mickael,
I agree. I've added this to Castor at past jobs. It is very helpful. I'll
try to patch SQLEngine over the weekend.
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
