I would propose that something like
driver.SetParameterValue(IDbCommand command, string paramName,
object value, DbType dbType)
driver.GetParameterValue(...)
be introduced. The built-in ITypes such as TimeType or
TimeAsTimeSpanType would call this function when they need to set a
"standard" type of value. This would allow users to keep the same
IType mapping (between system type and database type) and the driver
would abstract away the specifics of how to set a particular type of
value as a parameter. Note that this needn't be called for every
database-specific user created IType... it only really matters for
standard types since non-standard types can safely set the database
parameter values without problems anyways. Ultimately, authors of
non-standard types could choose to use the driver.SetParameter() if
they wanted that abstraction as well. Basically, it won't break any
existing ITypes or existing HBMs and would allow for database or
provider-specific details to be handled without exposing the
complication to the user.
This approach allows us to solve the following two existing problems:
-Conversion of DateTime/DbType.Time into NpgsqlTime within the
driver to work around a provider bug.
-Conversion of DateTime/DbType.Time into TimeSpan/SqlDbType.Time
to work around .NET 4 SQL 2008 provider differences.
I hope I'm not missing anything. In my eyes this approach is much
preferable to the introduction of new ITypes to deal with the
differences in parameter types. It would allow the IType mapping to
remain primarily between system type and database type and let the
driver figure out how to shuffle the data around. This would also
remove the existing hacks where the Getters for ITypes have to handle
two types of values coming back from the database. It also solves the
parameter set problem elegantly IMHO.
Thoughts?
Patrick Earl
