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 Don Dwoske <do...@loraxis.com> on 2006/09/21 16:29:54 UTC

using public fields instead of properties ?

I see this in the documentation :

3.5.4. <result> Elements
The <resultMap> element holds one or more <result> child elements that
map SQL resultsets to object properties.

3.5.4.1. property
The property attribute is the name of a **field** or a property of the
result object that will be returned by the Mapped Statement. The name
can be used more than once depending on the number of times it is
needed to populate the results.


If I try to use a public field, iBatis does not work.  The way .NET
properties are implemented - it's easy to start by using public
fields, then switch to using getters and setters later.  This is nice
because I find getters and setters to be verbose and painful in the
beginning... I know it's not "best practice" - but....

are the use of public properties expected to be supported by iBatis.NET anytime?




-- 

---------------------------------------
Donald Dwoske
Software Journeyman
http://www.loraxis.com/ddwoske

Re: using public fields instead of properties ?

Posted by Gilles Bayon <ib...@gmail.com>.
If you find an issue you can make a JIRA issue and attach a patch with
a unit test.

For private/public filed/propertis you can find unit tests in
E:\Projet\iBatis\trunk\cs\mapper\IBatisNet.Common.Test\NUnit\CommonTests\Utilities.

You can also find usage in IBatisNet.DataMapper.Test.

Sample :
Class
	/// <summary>
	/// Account.
	/// </summary>
	[Serializable]
	public class Account
	{
		private int id;
...

Mapping
<resultMap id="account-result"  class="Account" >
	<result property="id"           column="Account_ID"/>

-- 
Cheers,
Gilles

<a href="http://www.amazon.com/gp/registry/6JCP7AORB0LE">Wish List</a>

Re: using public fields instead of properties ?

Posted by Don Dwoske <do...@loraxis.com>.
Is this list alive?  .. not much traffic.

I had to *really* dig into stuff that I don't know about here, and I
think I found a bug which I fixed.

It's in DelegateSetFieldAccessor.cs where it's generating IL code to set Fields.

New code

                ilgen.Emit(OpCodes.Ldarg_0);
                ilgen.Emit(OpCodes.Ldarg_1);
                UnboxIfNeeded(fieldInfo.FieldType, ilgen);
                ilgen.Emit(OpCodes.Stfld, fieldInfo);
                ilgen.Emit(OpCodes.Ret);

and
        private static void UnboxIfNeeded(Type type, ILGenerator generator)
        {
            if (type.IsValueType)
            {
                generator.Emit(OpCodes.Unbox_Any, type);
            }
        }


old code

                ilgen.Emit(OpCodes.Ldarg_0);//Load the first argument
(target object)
                ilgen.Emit(OpCodes.Castclass, targetObjectType);
//Cast to the source type
                ilgen.Emit(OpCodes.Ldarg_1);//Load the second argument
(value object)
                if (_fieldType.IsValueType)
                {
                    ilgen.Emit(OpCodes.Unbox, _fieldType); //Unbox it 	
                    if (typeToOpcode[_fieldType] != null)
                    {
                        OpCode load = (OpCode)typeToOpcode[_fieldType];
                        ilgen.Emit(load); //and load
                    }
                    else
                    {
                        ilgen.Emit(OpCodes.Ldobj, _fieldType);
                    }
                    ilgen.Emit(OpCodes.Stfld, fieldInfo); //Set the field value
                }
                else
                {
                    ilgen.Emit(OpCodes.Castclass, _fieldType); //Cast class
                }

                ilgen.Emit(OpCodes.Ret);

got some info from here :
http://www.codeproject.com/useritems/Dynamic_Code_Generation.asp

there isn't much difference there, but whatever it was fixed it.

when I have breating room, I'll try and contact a developer on the
project who can verify the bug and fix to get it integrated into the
code base... or help explain it to me :-)


On 9/21/06, Don Dwoske <do...@loraxis.com> wrote:
> I'm digging into this myself, it appears that there is support for
> Fields - althought I can't really find any examples... but I'm getting
> this exception when using a public field instead of a property  (.NET
> 2.0 and DataMapper 1.5.1) :
>
> Unhandled Exception: System.InvalidProgramException: Common Language
> Runtime detected an invalid program.
>    at SetImplementation(Object , Object )
>    at IBatisNet.Common.Utilities.Objects.Members.DelegateFieldSetAccessor.SetValue.Invoke(Object
> instance, Object value)
>
>    at IBatisNet.Common.Utilities.Objects.Members.DelegateFieldSetAccessor.Set(Object
> target, Object value) in C:\novarti
> s\remoteReg\lwa\third-party\DataMapper-Source\IBatisNet.Common\Utilities\Objects\Members\DelegateSetFieldAccessor.cs:lin
> e 147
>    at IBatisNet.DataMapper.DataExchange.DotNetObjectDataExchange.SetData(Object&
> target, ResultProperty mapping, Object
> dataBaseValue) in
> C:\novartis\remoteReg\lwa\third-party\DataMapper-Source\IBatisNet.DataMapper\DataExchange\DotNetObject
> DataExchange.cs:line 95
>    at IBatisNet.DataMapper.Configuration.ResultMapping.ResultMap.SetValueOfProperty(Object&
> target, ResultProperty prope
> rty, Object dataBaseValue) in
> C:\novartis\remoteReg\lwa\third-party\DataMapper-Source\IBatisNet.DataMapper\Configuration
>
>
> On 9/21/06, Don Dwoske <do...@loraxis.com> wrote:
> > I see this in the documentation :
> >
> > 3.5.4. <result> Elements
> > The <resultMap> element holds one or more <result> child elements that
> > map SQL resultsets to object properties.
> >
> > 3.5.4.1. property
> > The property attribute is the name of a **field** or a property of the
> > result object that will be returned by the Mapped Statement. The name
> > can be used more than once depending on the number of times it is
> > needed to populate the results.
> >
> >
> > If I try to use a public field, iBatis does not work.  The way .NET
> > properties are implemented - it's easy to start by using public
> > fields, then switch to using getters and setters later.  This is nice
> > because I find getters and setters to be verbose and painful in the
> > beginning... I know it's not "best practice" - but....
> >
> > are the use of public properties expected to be supported by iBatis.NET anytime?
> >
> >
> >
> >
> > --
> >
> > ---------------------------------------
> > Donald Dwoske
> > Software Journeyman
> > http://www.loraxis.com/ddwoske
> >
>
>
> --
>
> ---------------------------------------
> Donald Dwoske
> Software Journeyman
> http://www.loraxis.com/ddwoske
>


-- 

---------------------------------------
Donald Dwoske
Software Journeyman
http://www.loraxis.com/ddwoske

Re: using public fields instead of properties ?

Posted by Don Dwoske <do...@loraxis.com>.
I'm digging into this myself, it appears that there is support for
Fields - althought I can't really find any examples... but I'm getting
this exception when using a public field instead of a property  (.NET
2.0 and DataMapper 1.5.1) :

Unhandled Exception: System.InvalidProgramException: Common Language
Runtime detected an invalid program.
   at SetImplementation(Object , Object )
   at IBatisNet.Common.Utilities.Objects.Members.DelegateFieldSetAccessor.SetValue.Invoke(Object
instance, Object value)

   at IBatisNet.Common.Utilities.Objects.Members.DelegateFieldSetAccessor.Set(Object
target, Object value) in C:\novarti
s\remoteReg\lwa\third-party\DataMapper-Source\IBatisNet.Common\Utilities\Objects\Members\DelegateSetFieldAccessor.cs:lin
e 147
   at IBatisNet.DataMapper.DataExchange.DotNetObjectDataExchange.SetData(Object&
target, ResultProperty mapping, Object
dataBaseValue) in
C:\novartis\remoteReg\lwa\third-party\DataMapper-Source\IBatisNet.DataMapper\DataExchange\DotNetObject
DataExchange.cs:line 95
   at IBatisNet.DataMapper.Configuration.ResultMapping.ResultMap.SetValueOfProperty(Object&
target, ResultProperty prope
rty, Object dataBaseValue) in
C:\novartis\remoteReg\lwa\third-party\DataMapper-Source\IBatisNet.DataMapper\Configuration


On 9/21/06, Don Dwoske <do...@loraxis.com> wrote:
> I see this in the documentation :
>
> 3.5.4. <result> Elements
> The <resultMap> element holds one or more <result> child elements that
> map SQL resultsets to object properties.
>
> 3.5.4.1. property
> The property attribute is the name of a **field** or a property of the
> result object that will be returned by the Mapped Statement. The name
> can be used more than once depending on the number of times it is
> needed to populate the results.
>
>
> If I try to use a public field, iBatis does not work.  The way .NET
> properties are implemented - it's easy to start by using public
> fields, then switch to using getters and setters later.  This is nice
> because I find getters and setters to be verbose and painful in the
> beginning... I know it's not "best practice" - but....
>
> are the use of public properties expected to be supported by iBatis.NET anytime?
>
>
>
>
> --
>
> ---------------------------------------
> Donald Dwoske
> Software Journeyman
> http://www.loraxis.com/ddwoske
>


-- 

---------------------------------------
Donald Dwoske
Software Journeyman
http://www.loraxis.com/ddwoske