You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-cs@ibatis.apache.org by Maxime Levesque <ma...@mail.mcgill.ca> on 2005/04/26 17:22:12 UTC
bug fix for oracle's odp.net driver
It was indeed a bug (at least with my definition of bug...)
To recapitulate (again) : insertion of strings (as varchar2) end up as null
in the DB.
The Microsoft driver is not affected by this, but for us it is not an option
(we need the extra
features of the oracle driver).
The fix involves a change in the class :
IBatisNet.DataMapper.MappedStatements.MappedStatement
// FIX BEGIN (line 225)
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
&&
!sqlParameter.DbType.Equals(System.Data.DbType.String))
((IDbDataParameter)parameterCopy).Size =
((IDbDataParameter)sqlParameter).Size;
// END FIX
A few non public fields of oracle's connection differ when
IDbDataParameter.Size is set
- Not good (when Size set to 0) :
m_maxSize 0 int
m_modified true bool
m_precision 0 byte
- Good (when Size set never set) :
m_maxSize -1 int
m_modified false bool
m_precision 100 byte
My conclusion is that no one else is using ibatis + oracle's odp.net
together, and your test suite probably doesn't include the combination,
Which leaves me a bit worried of using iBatis for our project.
On the other hand, I like the fact that ibatis leaves full control
of the sql/stored procs, but using an untested driver is risky
(this is a commercial project).
So, is this driver supported, or will it be in the very
Near future ? (i.e. will the odp.net driver be
Tested as part of the nunit test suite ) ?
private void ApplyParameterMap
( IDalSession session, IDbCommand command,
RequestScope request, object parameterObject )
{
ArrayList properties =
request.PreparedStatement.DbParametersName;
ArrayList parameters =
request.PreparedStatement.DbParameters;
for ( int i = 0; i < properties.Count; ++i )
{
IDataParameter sqlParameter =
(IDataParameter)parameters[i];
string propertyName = (string)properties[i];
if (command.CommandType == CommandType.Text)
{
if ( propertyName != "value" ) //
Inline Parameters && Parameters via ParameterMap
{
ParameterProperty property =
request.ParameterMap.GetProperty(i);
sqlParameter.Value =
request.ParameterMap.GetValueOfProperty(parameterObject,
property.PropertyName);
}
else // 'value' parameter
{
sqlParameter.Value =
parameterObject;
}
}
else // CommandType.StoredProcedure
{
// A store procedure must always use
a ParameterMap
// to indicate the mapping order of
the properties to the columns
if (request.ParameterMap == null) //
Inline Parameters
{
throw new
DataMapperException("A procedure statement tag must alway have a
parameterMap attribut, which is not the case for the procedure
'"+_statement.Id+"'.");
}
else // Parameters via ParameterMap
{
ParameterProperty property =
request.ParameterMap.GetProperty(i);
if
(property.DirectionAttribut.Length == 0)
{
property.Direction =
sqlParameter.Direction;
}
// IDbDataParameter
dataParameter = (IDbDataParameter)parameters[i];
// property.Precision =
dataParameter.Precision;
// property.Scale =
dataParameter.Scale;
// property.Size =
dataParameter.Size;
sqlParameter.Direction =
property.Direction;
sqlParameter.Value =
request.ParameterMap.GetValueOfProperty( parameterObject,
property.PropertyName );
}
}
IDataParameter parameterCopy =
command.CreateParameter();
parameterCopy.Value = sqlParameter.Value;
parameterCopy.Direction =
sqlParameter.Direction;
// With a ParameterMap, we could specify the
ParameterDbTypeProperty
if (_statement.ParameterMap != null)
{
if
(request.ParameterMap.GetProperty(i).DbType.Length >0)
{
string dbTypePropertyName =
session.DataSource.Provider.ParameterDbTypeProperty;
ObjectProbe.SetPropertyValue(parameterCopy, dbTypePropertyName,
ObjectProbe.GetPropertyValue(sqlParameter, dbTypePropertyName));
}
else
{
parameterCopy.DbType =
sqlParameter.DbType;
}
}
else
{
parameterCopy.DbType =
sqlParameter.DbType;
}
// FIX BEGIN :
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
&&
!sqlParameter.DbType.Equals(System.Data.DbType.String))
((IDbDataParameter)parameterCopy).Size =
((IDbDataParameter)sqlParameter).Size;
// END FIX...
((IDbDataParameter)parameterCopy).Precision
= ((IDbDataParameter)sqlParameter).Precision;
((IDbDataParameter)parameterCopy).Scale =
((IDbDataParameter)sqlParameter).Scale;
parameterCopy.ParameterName =
sqlParameter.ParameterName;
command.Parameters.Add(parameterCopy);
}
}
RE: bug fix for oracle's odp.net driver
Posted by Roberto Rabe <ro...@apache.org>.
Ahhh...I missed the "!"/not equals.
Definitely not a pain! The more feedback, the better for the code and
user-base!
Roberto
On Tue, April 26, 2005 12:40, Maxime Levesque said:
>
> Don't want to be a pain here, but the fix is to
> *not* set the Size property, which the latest version does :
>
> http://svn.apache.org/repos/asf/incubator/ibatis/trunk/cs/mapper/IBatisNet.D
> ataMapper/Commands/EmbedParamsPreparedCommand.cs
>
> on line 139 ...
>
> note that the code has moved to EmbedParamsPreparedCommand.cs ...
>
>
>> The latest source does do the setting of parameter size copy,
>
>
>
> -----Original Message-----
> From: Roberto Rabe [mailto:roberto@apache.org]
> Sent: Tuesday, April 26, 2005 11:02 AM
> To: ibatis-user-cs@incubator.apache.org
> Subject: Re: bug fix for oracle's odp.net driver
>
> The latest source does do the setting of parameter size copy, and the test
> suite does include the ODP.NET driver (there are 2 directories containing
> maps for testing both the MS provider and ODP). :-)
>
> But yes, it may seem that more folks are using the MS driver based on the
> list traffic.
>
> Roberto
>
> On Tue, April 26, 2005 11:22, Maxime Levesque said:
>>
>> It was indeed a bug (at least with my definition of bug...)
>>
>> To recapitulate (again) : insertion of strings (as varchar2) end up as
>> null
>> in the DB.
>>
>> The Microsoft driver is not affected by this, but for us it is not an
>> option
>> (we need the extra
>> features of the oracle driver).
>>
>> The fix involves a change in the class :
>>
>> IBatisNet.DataMapper.MappedStatements.MappedStatement
>>
>> // FIX BEGIN (line 225)
>>
>>
> if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
>> &&
>> !sqlParameter.DbType.Equals(System.Data.DbType.String))
>> ((IDbDataParameter)parameterCopy).Size
>> ((IDbDataParameter)sqlParameter).Size;
>> // END FIX
>>
>> A few non public fields of oracle's connection differ when
>> IDbDataParameter.Size is set
>>
>> - Not good (when Size set to 0) :
>> m_maxSize 0 int
>> m_modified true bool
>> m_precision 0 byte
>>
>> - Good (when Size set never set) :
>> m_maxSize -1 int
>> m_modified false bool
>> m_precision 100 byte
>>
>>
>> My conclusion is that no one else is using ibatis + oracle's odp.net
>> together, and your test suite probably doesn't include the combination,
>> Which leaves me a bit worried of using iBatis for our project.
>>
>> On the other hand, I like the fact that ibatis leaves full control
>> of the sql/stored procs, but using an untested driver is risky
>> (this is a commercial project).
>>
>> So, is this driver supported, or will it be in the very
>> Near future ? (i.e. will the odp.net driver be
>> Tested as part of the nunit test suite ) ?
>>
>
>
>
RE: bug fix for oracle's odp.net driver
Posted by Maxime Levesque <ma...@mail.mcgill.ca>.
Don't want to be a pain here, but the fix is to
*not* set the Size property, which the latest version does :
http://svn.apache.org/repos/asf/incubator/ibatis/trunk/cs/mapper/IBatisNet.D
ataMapper/Commands/EmbedParamsPreparedCommand.cs
on line 139 ...
note that the code has moved to EmbedParamsPreparedCommand.cs ...
> The latest source does do the setting of parameter size copy,
-----Original Message-----
From: Roberto Rabe [mailto:roberto@apache.org]
Sent: Tuesday, April 26, 2005 11:02 AM
To: ibatis-user-cs@incubator.apache.org
Subject: Re: bug fix for oracle's odp.net driver
The latest source does do the setting of parameter size copy, and the test
suite does include the ODP.NET driver (there are 2 directories containing
maps for testing both the MS provider and ODP). :-)
But yes, it may seem that more folks are using the MS driver based on the
list traffic.
Roberto
On Tue, April 26, 2005 11:22, Maxime Levesque said:
>
> It was indeed a bug (at least with my definition of bug...)
>
> To recapitulate (again) : insertion of strings (as varchar2) end up as
> null
> in the DB.
>
> The Microsoft driver is not affected by this, but for us it is not an
> option
> (we need the extra
> features of the oracle driver).
>
> The fix involves a change in the class :
>
> IBatisNet.DataMapper.MappedStatements.MappedStatement
>
> // FIX BEGIN (line 225)
>
>
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
> &&
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX
>
> A few non public fields of oracle's connection differ when
> IDbDataParameter.Size is set
>
> - Not good (when Size set to 0) :
> m_maxSize 0 int
> m_modified true bool
> m_precision 0 byte
>
> - Good (when Size set never set) :
> m_maxSize -1 int
> m_modified false bool
> m_precision 100 byte
>
>
> My conclusion is that no one else is using ibatis + oracle's odp.net
> together, and your test suite probably doesn't include the combination,
> Which leaves me a bit worried of using iBatis for our project.
>
> On the other hand, I like the fact that ibatis leaves full control
> of the sql/stored procs, but using an untested driver is risky
> (this is a commercial project).
>
> So, is this driver supported, or will it be in the very
> Near future ? (i.e. will the odp.net driver be
> Tested as part of the nunit test suite ) ?
>
Re: bug fix for oracle's odp.net driver
Posted by Roberto Rabe <ro...@apache.org>.
The latest source does do the setting of parameter size copy, and the test
suite does include the ODP.NET driver (there are 2 directories containing
maps for testing both the MS provider and ODP). :-)
But yes, it may seem that more folks are using the MS driver based on the
list traffic.
Roberto
On Tue, April 26, 2005 11:22, Maxime Levesque said:
>
> It was indeed a bug (at least with my definition of bug...)
>
> To recapitulate (again) : insertion of strings (as varchar2) end up as
> null
> in the DB.
>
> The Microsoft driver is not affected by this, but for us it is not an
> option
> (we need the extra
> features of the oracle driver).
>
> The fix involves a change in the class :
>
> IBatisNet.DataMapper.MappedStatements.MappedStatement
>
> // FIX BEGIN (line 225)
>
> if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
> &&
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX
>
> A few non public fields of oracle's connection differ when
> IDbDataParameter.Size is set
>
> - Not good (when Size set to 0) :
> m_maxSize 0 int
> m_modified true bool
> m_precision 0 byte
>
> - Good (when Size set never set) :
> m_maxSize -1 int
> m_modified false bool
> m_precision 100 byte
>
>
> My conclusion is that no one else is using ibatis + oracle's odp.net
> together, and your test suite probably doesn't include the combination,
> Which leaves me a bit worried of using iBatis for our project.
>
> On the other hand, I like the fact that ibatis leaves full control
> of the sql/stored procs, but using an untested driver is risky
> (this is a commercial project).
>
> So, is this driver supported, or will it be in the very
> Near future ? (i.e. will the odp.net driver be
> Tested as part of the nunit test suite ) ?
>
RE: bug fix for oracle's odp.net driver
Posted by roberto <ro...@theaegis.org>.
Yes, please add the issue to JIRA.
Roberto
On Tue, April 26, 2005 12:31, Ron Grabowski said:
> --- Maxime Levesque <ma...@mail.mcgill.ca> wrote:
>> My conclusion is that no one else is using ibatis + oracle's odp.net
>>
>> together, and your test suite probably doesn't include the
>> combination,
>> Which leaves me a bit worried of using iBatis for our project.
>>
>> On the other hand, I like the fact that ibatis leaves full control
>> of the sql/stored procs, but using an untested driver is risky
>> (this is a commercial project).
>>
>> So, is this driver supported, or will it be in the very
>> Near future ? (i.e. will the odp.net driver be
>> Tested as part of the nunit test suite ) ?
>
> Keep in mind that this is still a 1.x release. Its not possible to test
> every combination of .Net connection drivers. I'm sure more will be
> added to the test suite as time goes on.
>
> If the provider exhibits strange behaviour (I saw a comment in the
> source code about the MySql provider not supporting the CommandTimeOut
> property) then IBatisNet can only do so much. Deep down, IBatisNet just
> calls members of the System.Data interface.
>
>>>From glancing at the providers.config file, I see 8 providers. If
> everything is working fine for all of those providers and some new
> provider is exhibiting strange behaviour I would say there's something
> wrong with the provider. Perhaps you could spend some of the time saved
> from using IBatisNet to port the test cases to your Oracle provider.
>
> I can understand your frustration with things not working. There only
> seems to be two people using IBatisNet and Access (myself and another
> lurker on the list). I've been able to track down the issues I was
> having and they have since been corrected in the latest version in
> source control.
>
> You should report this in the issue tracker:
>
> http://issues.apache.org/jira/browse/IBATISNET
>
> Perhaps another attribute could be added to the <provider>
> node...something along the lines of:
>
> setParameterSizeIfNotDbString="false"
>
> That might fix issues with future providers as well.
>
Re: bug fix for oracle's odp.net driver
Posted by Gilles Bayon <ib...@gmail.com>.
The size property is set for ALL DbTypes and we will not make
exception for one DbType and not for an other.
We try to make generic code and not specific code, if SQLite.NET
provider is a special provider, ask SQLite.NET team to modify their
code to follow .NET guidelance.
We have introduced the generic size/precision/scale properties on
provider to try to fix odp.net and by the way some SQLite.NET issue
but we will not go on specific code.
-Gilles
RE: bug fix for oracle's odp.net driver
Posted by Roberto Rabe <ro...@apache.org>.
Yes, please add the issue to JIRA.
Roberto
On Tue, April 26, 2005 12:31, Ron Grabowski said:
> You should report this in the issue tracker:
>
> http://issues.apache.org/jira/browse/IBATISNET
>
> Perhaps another attribute could be added to the <provider>
> node...something along the lines of:
>
> setParameterSizeIfNotDbString="false"
>
> That might fix issues with future providers as well.
>
RE: bug fix for oracle's odp.net driver
Posted by Ron Grabowski <ro...@yahoo.com>.
Does your code work correctly if the Size property is not set for all
DbTypes?
There is code in SVN now that allows a <provider> to specify which
IDbDataParameter properties to set: Precision, Scale, and/or Size.
There currently isn't any way to specify what properties to set or not
set based on DbType. For example its not possible to set the Size
property on all DbTypes except for Strings. Does that make sense?
- Ron
--- Maxime Levesque <ma...@mail.mcgill.ca> wrote:
>
> oops, bug in the fix...
>
> // FIX BEGIN line 225:
>
>
if(command.GetType().FullName.Equals("Oracle.DataAccess.Client.OracleCommand
> ")
> &&
>
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size =
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX...
>
>
> -----Original Message-----
> From: Maxime Levesque [mailto:maxime.levesque@mail.mcgill.ca]
> Sent: Tuesday, April 26, 2005 10:22 AM
> To: ibatis-user-cs@incubator.apache.org
> Subject: bug fix for oracle's odp.net driver
>
>
> It was indeed a bug (at least with my definition of bug...)
>
> To recapitulate (again) : insertion of strings (as varchar2) end up
> as null
> in the DB.
>
> The Microsoft driver is not affected by this, but for us it is not an
> option
> (we need the extra
> features of the oracle driver).
>
> The fix involves a change in the class :
>
> IBatisNet.DataMapper.MappedStatements.MappedStatement
>
> // FIX BEGIN (line 225)
>
>
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
> &&
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size =
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX
>
> A few non public fields of oracle's connection differ when
> IDbDataParameter.Size is set
>
> - Not good (when Size set to 0) :
> m_maxSize 0 int
> m_modified true bool
> m_precision 0 byte
>
> - Good (when Size set never set) :
> m_maxSize -1 int
> m_modified false bool
> m_precision 100 byte
>
>
> My conclusion is that no one else is using ibatis + oracle's odp.net
>
> together, and your test suite probably doesn't include the
> combination,
> Which leaves me a bit worried of using iBatis for our project.
>
> On the other hand, I like the fact that ibatis leaves full control
> of the sql/stored procs, but using an untested driver is risky
> (this is a commercial project).
>
> So, is this driver supported, or will it be in the very
> Near future ? (i.e. will the odp.net driver be
> Tested as part of the nunit test suite ) ?
>
>
> private void ApplyParameterMap
> ( IDalSession session, IDbCommand command,
> RequestScope request, object parameterObject )
> {
> ArrayList properties =
> request.PreparedStatement.DbParametersName;
> ArrayList parameters =
> request.PreparedStatement.DbParameters;
>
> for ( int i = 0; i < properties.Count; ++i )
> {
> IDataParameter sqlParameter =
> (IDataParameter)parameters[i];
> string propertyName = (string)properties[i];
>
> if (command.CommandType == CommandType.Text)
> {
> if ( propertyName != "value" ) //
> Inline Parameters && Parameters via ParameterMap
> {
> ParameterProperty property =
> request.ParameterMap.GetProperty(i);
>
> sqlParameter.Value =
> request.ParameterMap.GetValueOfProperty(parameterObject,
>
> property.PropertyName);
> }
> else // 'value' parameter
> {
> sqlParameter.Value =
> parameterObject;
> }
> }
> else // CommandType.StoredProcedure
> {
> // A store procedure must always use
> a ParameterMap
> // to indicate the mapping order of
> the properties to the columns
> if (request.ParameterMap == null) //
> Inline Parameters
> {
> throw new
> DataMapperException("A procedure statement tag must alway have a
> parameterMap attribut, which is not the case for the procedure
> '"+_statement.Id+"'.");
> }
> else // Parameters via ParameterMap
> {
> ParameterProperty property =
> request.ParameterMap.GetProperty(i);
>
> if
> (property.DirectionAttribut.Length == 0)
> {
> property.Direction =
> sqlParameter.Direction;
> }
>
> // IDbDataParameter
> dataParameter = (IDbDataParameter)parameters[i];
> // property.Precision =
> dataParameter.Precision;
> // property.Scale =
> dataParameter.Scale;
> // property.Size =
> dataParameter.Size;
>
> sqlParameter.Direction =
> property.Direction;
> sqlParameter.Value =
> request.ParameterMap.GetValueOfProperty( parameterObject,
> property.PropertyName );
> }
> }
>
> IDataParameter parameterCopy =
> command.CreateParameter();
> parameterCopy.Value = sqlParameter.Value;
>
> parameterCopy.Direction =
> sqlParameter.Direction;
>
> // With a ParameterMap, we could specify the
> ParameterDbTypeProperty
> if (_statement.ParameterMap != null)
> {
> if
> (request.ParameterMap.GetProperty(i).DbType.Length >0)
> {
> string dbTypePropertyName =
> session.DataSource.Provider.ParameterDbTypeProperty;
>
>
> ObjectProbe.SetPropertyValue(parameterCopy, dbTypePropertyName,
> ObjectProbe.GetPropertyValue(sqlParameter, dbTypePropertyName));
> }
> else
> {
> parameterCopy.DbType =
> sqlParameter.DbType;
> }
> }
> else
> {
> parameterCopy.DbType =
> sqlParameter.DbType;
> }
> // FIX BEGIN :
>
>
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
> &&
>
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size =
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX...
> ((IDbDataParameter)parameterCopy).Precision
> = ((IDbDataParameter)sqlParameter).Precision;
> ((IDbDataParameter)parameterCopy).Scale =
> ((IDbDataParameter)sqlParameter).Scale;
>
> parameterCopy.ParameterName =
> sqlParameter.ParameterName;
>
>
=== message truncated ===
RE: bug fix for oracle's odp.net driver
Posted by Ron Grabowski <ro...@yahoo.com>.
--- Maxime Levesque <ma...@mail.mcgill.ca> wrote:
> My conclusion is that no one else is using ibatis + oracle's odp.net
>
> together, and your test suite probably doesn't include the
> combination,
> Which leaves me a bit worried of using iBatis for our project.
>
> On the other hand, I like the fact that ibatis leaves full control
> of the sql/stored procs, but using an untested driver is risky
> (this is a commercial project).
>
> So, is this driver supported, or will it be in the very
> Near future ? (i.e. will the odp.net driver be
> Tested as part of the nunit test suite ) ?
Keep in mind that this is still a 1.x release. Its not possible to test
every combination of .Net connection drivers. I'm sure more will be
added to the test suite as time goes on.
If the provider exhibits strange behaviour (I saw a comment in the
source code about the MySql provider not supporting the CommandTimeOut
property) then IBatisNet can only do so much. Deep down, IBatisNet just
calls members of the System.Data interface.
>From glancing at the providers.config file, I see 8 providers. If
everything is working fine for all of those providers and some new
provider is exhibiting strange behaviour I would say there's something
wrong with the provider. Perhaps you could spend some of the time saved
from using IBatisNet to port the test cases to your Oracle provider.
I can understand your frustration with things not working. There only
seems to be two people using IBatisNet and Access (myself and another
lurker on the list). I've been able to track down the issues I was
having and they have since been corrected in the latest version in
source control.
You should report this in the issue tracker:
http://issues.apache.org/jira/browse/IBATISNET
Perhaps another attribute could be added to the <provider>
node...something along the lines of:
setParameterSizeIfNotDbString="false"
That might fix issues with future providers as well.
RE: bug fix for oracle's odp.net driver
Posted by Ron Grabowski <ro...@yahoo.com>.
I've also noticed this behaviour when trying to work with the
SQLite.NET provider:
http://sourceforge.net/projects/adodotnetsqlite
I've added an issue to Jira:
http://issues.apache.org/jira/browse/IBATISNET-49
--- Maxime Levesque <ma...@mail.mcgill.ca> wrote:
>
> oops, bug in the fix...
>
> // FIX BEGIN line 225:
>
>
if(command.GetType().FullName.Equals("Oracle.DataAccess.Client.OracleCommand
> ")
> &&
>
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size =
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX...
>
>
> -----Original Message-----
> From: Maxime Levesque [mailto:maxime.levesque@mail.mcgill.ca]
> Sent: Tuesday, April 26, 2005 10:22 AM
> To: ibatis-user-cs@incubator.apache.org
> Subject: bug fix for oracle's odp.net driver
>
>
> It was indeed a bug (at least with my definition of bug...)
>
> To recapitulate (again) : insertion of strings (as varchar2) end up
> as null
> in the DB.
>
> The Microsoft driver is not affected by this, but for us it is not an
> option
> (we need the extra
> features of the oracle driver).
>
> The fix involves a change in the class :
>
> IBatisNet.DataMapper.MappedStatements.MappedStatement
>
> // FIX BEGIN (line 225)
>
>
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
> &&
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size =
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX
>
> A few non public fields of oracle's connection differ when
> IDbDataParameter.Size is set
>
> - Not good (when Size set to 0) :
> m_maxSize 0 int
> m_modified true bool
> m_precision 0 byte
>
> - Good (when Size set never set) :
> m_maxSize -1 int
> m_modified false bool
> m_precision 100 byte
>
>
> My conclusion is that no one else is using ibatis + oracle's odp.net
>
> together, and your test suite probably doesn't include the
> combination,
> Which leaves me a bit worried of using iBatis for our project.
>
> On the other hand, I like the fact that ibatis leaves full control
> of the sql/stored procs, but using an untested driver is risky
> (this is a commercial project).
>
> So, is this driver supported, or will it be in the very
> Near future ? (i.e. will the odp.net driver be
> Tested as part of the nunit test suite ) ?
>
>
> private void ApplyParameterMap
> ( IDalSession session, IDbCommand command,
> RequestScope request, object parameterObject )
> {
> ArrayList properties =
> request.PreparedStatement.DbParametersName;
> ArrayList parameters =
> request.PreparedStatement.DbParameters;
>
> for ( int i = 0; i < properties.Count; ++i )
> {
> IDataParameter sqlParameter =
> (IDataParameter)parameters[i];
> string propertyName = (string)properties[i];
>
> if (command.CommandType == CommandType.Text)
> {
> if ( propertyName != "value" ) //
> Inline Parameters && Parameters via ParameterMap
> {
> ParameterProperty property =
> request.ParameterMap.GetProperty(i);
>
> sqlParameter.Value =
> request.ParameterMap.GetValueOfProperty(parameterObject,
>
> property.PropertyName);
> }
> else // 'value' parameter
> {
> sqlParameter.Value =
> parameterObject;
> }
> }
> else // CommandType.StoredProcedure
> {
> // A store procedure must always use
> a ParameterMap
> // to indicate the mapping order of
> the properties to the columns
> if (request.ParameterMap == null) //
> Inline Parameters
> {
> throw new
> DataMapperException("A procedure statement tag must alway have a
> parameterMap attribut, which is not the case for the procedure
> '"+_statement.Id+"'.");
> }
> else // Parameters via ParameterMap
> {
> ParameterProperty property =
> request.ParameterMap.GetProperty(i);
>
> if
> (property.DirectionAttribut.Length == 0)
> {
> property.Direction =
> sqlParameter.Direction;
> }
>
> // IDbDataParameter
> dataParameter = (IDbDataParameter)parameters[i];
> // property.Precision =
> dataParameter.Precision;
> // property.Scale =
> dataParameter.Scale;
> // property.Size =
> dataParameter.Size;
>
> sqlParameter.Direction =
> property.Direction;
> sqlParameter.Value =
> request.ParameterMap.GetValueOfProperty( parameterObject,
> property.PropertyName );
> }
> }
>
> IDataParameter parameterCopy =
> command.CreateParameter();
> parameterCopy.Value = sqlParameter.Value;
>
> parameterCopy.Direction =
> sqlParameter.Direction;
>
> // With a ParameterMap, we could specify the
> ParameterDbTypeProperty
> if (_statement.ParameterMap != null)
> {
> if
> (request.ParameterMap.GetProperty(i).DbType.Length >0)
> {
> string dbTypePropertyName =
> session.DataSource.Provider.ParameterDbTypeProperty;
>
>
> ObjectProbe.SetPropertyValue(parameterCopy, dbTypePropertyName,
> ObjectProbe.GetPropertyValue(sqlParameter, dbTypePropertyName));
> }
> else
> {
> parameterCopy.DbType =
> sqlParameter.DbType;
> }
> }
> else
> {
> parameterCopy.DbType =
> sqlParameter.DbType;
> }
> // FIX BEGIN :
>
>
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
> &&
>
> !sqlParameter.DbType.Equals(System.Data.DbType.String))
> ((IDbDataParameter)parameterCopy).Size =
> ((IDbDataParameter)sqlParameter).Size;
> // END FIX...
> ((IDbDataParameter)parameterCopy).Precision
> = ((IDbDataParameter)sqlParameter).Precision;
> ((IDbDataParameter)parameterCopy).Scale =
> ((IDbDataParameter)sqlParameter).Scale;
>
> parameterCopy.ParameterName =
> sqlParameter.ParameterName;
>
>
=== message truncated ===
RE: bug fix for oracle's odp.net driver
Posted by Maxime Levesque <ma...@mail.mcgill.ca>.
oops, bug in the fix...
// FIX BEGIN line 225:
if(command.GetType().FullName.Equals("Oracle.DataAccess.Client.OracleCommand
")
&&
!sqlParameter.DbType.Equals(System.Data.DbType.String))
((IDbDataParameter)parameterCopy).Size =
((IDbDataParameter)sqlParameter).Size;
// END FIX...
-----Original Message-----
From: Maxime Levesque [mailto:maxime.levesque@mail.mcgill.ca]
Sent: Tuesday, April 26, 2005 10:22 AM
To: ibatis-user-cs@incubator.apache.org
Subject: bug fix for oracle's odp.net driver
It was indeed a bug (at least with my definition of bug...)
To recapitulate (again) : insertion of strings (as varchar2) end up as null
in the DB.
The Microsoft driver is not affected by this, but for us it is not an option
(we need the extra
features of the oracle driver).
The fix involves a change in the class :
IBatisNet.DataMapper.MappedStatements.MappedStatement
// FIX BEGIN (line 225)
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
&&
!sqlParameter.DbType.Equals(System.Data.DbType.String))
((IDbDataParameter)parameterCopy).Size =
((IDbDataParameter)sqlParameter).Size;
// END FIX
A few non public fields of oracle's connection differ when
IDbDataParameter.Size is set
- Not good (when Size set to 0) :
m_maxSize 0 int
m_modified true bool
m_precision 0 byte
- Good (when Size set never set) :
m_maxSize -1 int
m_modified false bool
m_precision 100 byte
My conclusion is that no one else is using ibatis + oracle's odp.net
together, and your test suite probably doesn't include the combination,
Which leaves me a bit worried of using iBatis for our project.
On the other hand, I like the fact that ibatis leaves full control
of the sql/stored procs, but using an untested driver is risky
(this is a commercial project).
So, is this driver supported, or will it be in the very
Near future ? (i.e. will the odp.net driver be
Tested as part of the nunit test suite ) ?
private void ApplyParameterMap
( IDalSession session, IDbCommand command,
RequestScope request, object parameterObject )
{
ArrayList properties =
request.PreparedStatement.DbParametersName;
ArrayList parameters =
request.PreparedStatement.DbParameters;
for ( int i = 0; i < properties.Count; ++i )
{
IDataParameter sqlParameter =
(IDataParameter)parameters[i];
string propertyName = (string)properties[i];
if (command.CommandType == CommandType.Text)
{
if ( propertyName != "value" ) //
Inline Parameters && Parameters via ParameterMap
{
ParameterProperty property =
request.ParameterMap.GetProperty(i);
sqlParameter.Value =
request.ParameterMap.GetValueOfProperty(parameterObject,
property.PropertyName);
}
else // 'value' parameter
{
sqlParameter.Value =
parameterObject;
}
}
else // CommandType.StoredProcedure
{
// A store procedure must always use
a ParameterMap
// to indicate the mapping order of
the properties to the columns
if (request.ParameterMap == null) //
Inline Parameters
{
throw new
DataMapperException("A procedure statement tag must alway have a
parameterMap attribut, which is not the case for the procedure
'"+_statement.Id+"'.");
}
else // Parameters via ParameterMap
{
ParameterProperty property =
request.ParameterMap.GetProperty(i);
if
(property.DirectionAttribut.Length == 0)
{
property.Direction =
sqlParameter.Direction;
}
// IDbDataParameter
dataParameter = (IDbDataParameter)parameters[i];
// property.Precision =
dataParameter.Precision;
// property.Scale =
dataParameter.Scale;
// property.Size =
dataParameter.Size;
sqlParameter.Direction =
property.Direction;
sqlParameter.Value =
request.ParameterMap.GetValueOfProperty( parameterObject,
property.PropertyName );
}
}
IDataParameter parameterCopy =
command.CreateParameter();
parameterCopy.Value = sqlParameter.Value;
parameterCopy.Direction =
sqlParameter.Direction;
// With a ParameterMap, we could specify the
ParameterDbTypeProperty
if (_statement.ParameterMap != null)
{
if
(request.ParameterMap.GetProperty(i).DbType.Length >0)
{
string dbTypePropertyName =
session.DataSource.Provider.ParameterDbTypeProperty;
ObjectProbe.SetPropertyValue(parameterCopy, dbTypePropertyName,
ObjectProbe.GetPropertyValue(sqlParameter, dbTypePropertyName));
}
else
{
parameterCopy.DbType =
sqlParameter.DbType;
}
}
else
{
parameterCopy.DbType =
sqlParameter.DbType;
}
// FIX BEGIN :
if(typeof(command).FullName.Equals("Oracle.DataAccess.Client.OracleCommand")
&&
!sqlParameter.DbType.Equals(System.Data.DbType.String))
((IDbDataParameter)parameterCopy).Size =
((IDbDataParameter)sqlParameter).Size;
// END FIX...
((IDbDataParameter)parameterCopy).Precision
= ((IDbDataParameter)sqlParameter).Precision;
((IDbDataParameter)parameterCopy).Scale =
((IDbDataParameter)sqlParameter).Scale;
parameterCopy.ParameterName =
sqlParameter.ParameterName;
command.Parameters.Add(parameterCopy);
}
}