[
http://issues.apache.org/jira/browse/IBATISNET-35?page=comments#action_62697 ]
Ron Grabowski commented on IBATISNET-35:
----------------------------------------
Initially I thought a good starting point would be to add an abstract
LoggingPreparedCommand class that implemented IPreparedCommand and that other
class would inherifiy from (namely DefaultPreparedCommand). I don't think
that's a good idea becuase a user may call IDbCommand's Create method and never
actually connect to the database. In MappedStatement, there are 5 calls to the
various command Execute methods
ExecuteInsert - command.ExecuteScalar()
RunQueryForObject - command.ExecuteScalar()
ExecuteUpdate - command.ExecuteNonQuery()
RunQueryForList - command.ExecuteReader()
RunQueryForObject - command.ExecuteReader()
I think logging needs to take place directly before the call to Execute:
if (_logger.IsDebugEnabled)
{
_logger.Debug("Using Connection [" + command.Connection.GetHashCode() + "]");
_logger.Debug("PreparedStatement: [" + request.PreparedStatement.PreparedSql +
"]");
_logger.Debug("Parameters: [" + GenerateParametersString(request) + "]");
_logger.Debug("Types: [" + GenerateTypesString(request) + "]");
}
using ( IDataReader reader = command.ExecuteReader() )
{
...
The command.Connection information is displayed becuase the user may not be
using the DataAccess library in which case there would be no log information
about what connection is being used. Notice that the Java version of IBatis has
2 log messages dealing with connections for every trip to the database.
I don't know if its better to loop through the IDbParameters on the command
object to generate the string containing parameters or if its better to use the
values in the request. I would feel better looping through the values in the
command object so I was 100% certain that what was showing up in the logs was
what was actually being sent to the database. Its a shame we have to loop
through the parameters twice (once to attach them to the command object, then
once to generate the log message) but DEBUG level logging shouldn't be turned
on in production environment...
> Improve logging of text sent to database and recieved from database to match
> Java version of IBatis
> ---------------------------------------------------------------------------------------------------
>
> Key: IBATISNET-35
> URL: http://issues.apache.org/jira/browse/IBATISNET-35
> Project: iBatis for .NET
> Type: Improvement
> Versions: DataAccess 1.5, DataMapper 1.1
> Environment: Data Mapper - [assembly: AssemblyVersion("1.1.458")]
> Data Access - [assembly: AssemblyVersion("1.5.458")]
> Reporter: Ron Grabowski
>
> Here are some example logs from the Java version of IBatis. The examples show
> INSERT, SELECT, UPDATE, and DELETE statements:
> DEBUG - Checked out connection 30332961 from pool.
> DEBUG - {conn-100003} Connection
> DEBUG - {pstm-100004} PreparedStatement: INSERT INFO UserAudit (UserId,
> AuditEvent, DateOccurred) values (?,?,?)
> DEBUG - {pstm-100004} Parameters: [4, audit.login.success, 2004-08-25
> 09:15:22.809]
> DEBUG - {pstm-100004} Types: [java.lang.Integer, java.lang.String,
> java.sql.Timestamp]
> DEBUG - {pstm-100005} PreparedStatement: SELECT LAST_INSERT_ID() AS id
> DEBUG - {pstm-100005} Parameters: []
> DEBUG - {pstm-100005} Types: []
> DEBUG - {rset-100006} ResultSet
> DEBUG - {rset-100006} Header: [id]
> DEBUG - {rset-100006} Result: [422]
> DEBUG - Returned connection 30332961 to pool.
> DEBUG - Checked out connection 30332961 from pool.
> DEBUG - {conn-100007} Connection
> DEBUG - {pstm-100008} PreparedStatement: SELECT UserId, Login, Password FROM
> User WHERE Login = ? and Password = ?
> DEBUG - {pstm-100008} Parameters: [abc123, def456]
> DEBUG - {pstm-100008} Types: [java.lang.String, java.lang.String]
> DEBUG - {rset-100009} ResultSet
> DEBUG - {rset-100009} Header: [UserId, Login, Password]
> DEBUG - {rset-100009} Result: [4, abc1234, def456]
> DEBUG - Returned connection 30332961 to pool.
> DEBUG - Checked out connection 4548856 from pool.
> DEBUG - {conn-100045} Connection
> DEBUG - {pstm-100046} PreparedStatement: SELECT UserId, Login FROM User
> DEBUG - {pstm-100046} Parameters: []
> DEBUG - {pstm-100046} Types: []
> DEBUG - {rset-100047} ResultSet
> DEBUG - {rset-100047} Header: [UserId, Login]
> DEBUG - {rset-100047} Result: [1, abc123]
> DEBUG - {rset-100047} Result: [4, def456]
> DEBUG - {rset-100047} Result: [6, aaaaa]
> DEBUG - Returned connection 4548856 to pool.
> DEBUG - Checked out connection 7125805 from pool.
> DEBUG - {conn-100043} Connection
> DEBUG - {pstm-100044} PreparedStatement: UPDATE User SET Login = ? WHERE
> UserId = ?
> DEBUG - {pstm-100044} Parameters: [aaaaa, 4]
> DEBUG - {pstm-100044} Types: [java.lang.String, java.lang.Integer]
> DEBUG - Returned connection 7125805 to pool.
> DEBUG - Checked out connection 27062282 from pool.
> DEBUG - {conn-100043} Connection
> DEBUG - {pstm-100044} PreparedStatement: DELETE FROM User WHERE UserId = ?
> DEBUG - {pstm-100044} Parameters: [4]
> DEBUG - {pstm-100044} Types: [java.lang.Integer]
> DEBUG - Returned connection 27062282 to pool.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
