iBatis for .NET
  1. iBatis for .NET
  2. IBATISNET-158

TypeAssemblyInfo.SplitTypeAndAssemblyNames

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: DataMapper 1.3
    • Fix Version/s: DataMapper 1.5
    • Component/s: DataMapper
    • Labels:
      None

      Description

      Hi All:

      I'd like to propose a change to the TypeAssemblyInfo internal class within TypeResolver.cs. Please see the proposed code change below.

      private void SplitTypeAndAssemblyNames (string originalTypeName)

      {

      int typeAssemblyIndex

      // Original Code = originalTypeName.IndexOf (

      = originalTypeName.LastIndexOf (

      TypeAssemblyInfo.TypeAssemblySeparator);

      if (typeAssemblyIndex < 0)

      { unresolvedTypeName = originalTypeName; }

      else

      { unresolvedTypeName = originalTypeName.Substring ( 0, typeAssemblyIndex).Trim (); unresolvedAssemblyName = originalTypeName.Substring ( typeAssemblyIndex + 1).Trim (); }

      }

      Changing the call from IndexOf to LastIndexOf allows me to define a .Net 2.0 generic in the listClass attribute of a statement definition. You can see an example below. This syntax is impropertly parsed for a comma without this proposed change.

      <select id="LoadCodesByCategory" parameterMap="CodeData.CodeDataByCategoryParams" resultMap="LoadStateCode" listClass="System.Collections.Generic.List`1[[NFS.Data.Core.DataObjects.Impl.StateCode, NFS.Data.Impl]], mscorlib">

        Activity

        Hide
        Gilles Bayon added a comment -

        You don't need to specify a listClas, just use the generic syntax of QueryForList

        sqlMap.QueryForList<StateCode>( statementID, codeDataByCategoryParams)

        I will fix the issue.

        Show
        Gilles Bayon added a comment - You don't need to specify a listClas, just use the generic syntax of QueryForList sqlMap.QueryForList<StateCode>( statementID, codeDataByCategoryParams) I will fix the issue.
        Hide
        Gilles Bayon added a comment -

        In SVN

        Show
        Gilles Bayon added a comment - In SVN
        Hide
        Chris Potter added a comment -

        Hi Gilles:

        I'm a bit confused by both your comment and your fix. We're currently using version 1.3 which doesn't support the generic signatures of the QueryForList, etc., methods. It is also important to note we're using the ExecuteQueryForRowDelegate method extensively. In DataMapper 1.3, while it is true I can call QueryForList using the signature that takes any IList implementation, the same type of signature doesn't exist for the ExecuteQueryForRowDelegate call. This was my motivation for proposing this change. You stated you corrected the issue in 1.5, however, it appears to me you only handle my proposed change in the event the type name provided in listClass begins with "System.Nullable". In my case the typename begins with "System.Collections". Am I missing something? Also, is it possible to get the change I proposed into the 1.3 code base?

        Thanks,
        Chris

        Show
        Chris Potter added a comment - Hi Gilles: I'm a bit confused by both your comment and your fix. We're currently using version 1.3 which doesn't support the generic signatures of the QueryForList, etc., methods. It is also important to note we're using the ExecuteQueryForRowDelegate method extensively. In DataMapper 1.3, while it is true I can call QueryForList using the signature that takes any IList implementation, the same type of signature doesn't exist for the ExecuteQueryForRowDelegate call. This was my motivation for proposing this change. You stated you corrected the issue in 1.5, however, it appears to me you only handle my proposed change in the event the type name provided in listClass begins with "System.Nullable". In my case the typename begins with "System.Collections". Am I missing something? Also, is it possible to get the change I proposed into the 1.3 code base? Thanks, Chris
        Hide
        Gilles Bayon added a comment -

        I have redo the type resolver to support all generic type.
        You case should be handle by the current code even if you don't see your fix.

        See unit test IBatisNet.Common.Test.NUnit.CommonTests.Utilities.TypeResolverTest.

        -Gilles

        Show
        Gilles Bayon added a comment - I have redo the type resolver to support all generic type. You case should be handle by the current code even if you don't see your fix. See unit test IBatisNet.Common.Test.NUnit.CommonTests.Utilities.TypeResolverTest. -Gilles

          People

          • Assignee:
            Gilles Bayon
            Reporter:
            Chris Potter
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development