Fix NullPoint exception caused by missing TypeHandler

[fengxx]

Nested results were handled differently, a resultMap can run in simple query but not in netsted map, e.g.

    <resultMap id="referOrdersMap" type="java.lang.String">
      <result property="value" column="ref_id"/>
    </resultMap>

    <resultMap id="productResult" type="org.apache.ibatis.submitted.nestedresulthandler.Product">
        <result property="id" column="product_id" />
        <!-- use resultMap="referOrdersMap" instead of column="ref_id" to verify NPE in NestResultHandler-->
        <collection property="referOrders"  resultMap="referOrdersMap" javaType="list" ofType="java.lang.String"/> 
    </resultMap>

     <select id="getProducts" resultMap="productResult">
        select 'ID:'||order_id ref_id ,product_id
        from orderDetail
        order by product_id
     </select>

    <select id="getSimpleResult" resultMap="referOrdersMap">
        select 'ID:'||order_id ref_id from orderDetail
    </select>

getSimpleResult can run successfully but getProducts will throw null point exception.

The fix added null checking in createRowKeyForMappedProperties method and fall back to resultColumnCache.getTypeHandler if no type handler found.

[fengxx]

Rebased to avoid conflicts.

[emacarron]

Hi Ted.

I have just had a look at this and I would say that the resultMap is wrong. There is no "value" property in a String so the right one would be:

<resultMap id="referOrdersMap" type="java.lang.String">
  <result column="ref_id"/>
</resultMap>

And it that case, the test passes.

[fengxx]

Yes, String don't have value property, but "getSimpleResult" will return values without errors. the point is Nested query and Simple Query don't share some tolerance. The configuration which works in Simple Query throws errors in Nestedmap causes user frustrated.

[emacarron]

Having a deeper look at this it looks like the String type does have a "value" property!! It is a private property of type char[]. Seems that the problem is that there is not a typehandler for that type and it fails with a NPE.

This is related to #9. I suppose that the fix I did is not the right one because it should have produced a controlled failure also for this case but it did not. So I will try a different solution.

Once properly fixed both simple and nested queries should behave the same.