mybatis/generator

constructorBased & JavaModelwithBlobs issue

Opened this issue · 6 comments

Deleted user commented

Hello, now I use mybatis-generator very well.
But there is a problem when I used javaModelGenerator property "constructorBased".

image
This is my table structure.
We can see a TEXT type column "update_reason".
After generate I see the mapper and javaModel.

First in the Mapper File, I can see two resultMap.
image
image
There is no Record With BLOBs.
So two other resultMaps have same returnType.

Here's what happens:
writeMapper.selectByExample(example); // Exception!!
writeMapper.selectByExampleWithBLOBs((example); // success!!

Following Exception
Caused by: org.apache.ibatis.reflection.ReflectionException: Error instantiating class com.midasit.erp.generate.model.ERPCommute with invalid types (Date,Integer,Integer,Integer,String,String,String,String,Boolean,) or values (Wed Mar 22 00:00:00 KST 2017,13076,7363,3,0929,null,127.0.0.1,null,false,). Cause: java.lang.NoSuchMethodException: com.midasit.erp.generate.model.ERPCommute.<init>(java.util.Date, java.lang.Integer, java.lang.Integer, java.lang.Integer, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.Boolean)

Deleted user commented

p.s. My MBG version is 1.3.3 and defaultModelType is conditional.

jeffgbutler commented

I see the problem. I think the generator needs to add another constructor in this case - one that doesn't expect any BLOB fields. I'll fix it - thanks for reporting!

Deleted user commented

@jeffgbutler
How about use same criteria when generate mapper & record?
When defaultModelType is "conditional", and DB table has one or more Blob type column, mapper is generated resultMap withBLOBs.
But RecordWithBLOBs file is generated when Blob type column only two or more.

jeffgbutler commented

@TroyTae The thought behind the non-BLOB methods is that obtaining a BLOB column from the DB can be expensive, and is not always necessary. It is a bit uncertain what to do in this case since the BLOB fields are in the record - should the BLOB fields be ignored for the non-BLOB operations, or should we not generate the non-BLOB operations and always return the BLOBs? I'm inclined to the former for these reasons:

  1. It is an easy fix (just add a constructor that doesn't expect the BLOBs)
  2. It is more consistent with generated code from other model types and table types
Deleted user commented

@jeffgbutler
Oh I see. I didn't think the cost aspect.
If you don't mind, can i fix this bug?
I guess I'll fix BaseRecordGenerator.java.

jeffgbutler commented

@TroyTae Sure - I've written failing tests so far, but haven't done the fix yet.