MyBatis3DynamicSql generated SqlSupport static inner class names cause errors with identically named enums

[mahiarmody]

When using the MyBatis3DynamicSql target runtime for the MyBatis Generator (mbg), if the application defines an enum with the same name as the domainObjectName for a table, and specifies a column in that table to be of the enum type, in the mbg configuration file, then the generated update methods of the Mapper class have compile errors due to the wrong class being used.

The cause of the problem is not the generated Mapper class but in the generated DynamicSqlSupport class. The generic types of the SqlColumns of the static final inner class of the DynamicSqlSupport class should reference the enum class, not the static inner class extending SqlTable itself. Take a look at the example below:

Table Definition

create table Owner_Type
(
	owner_type_id IDENTITY(1,1) not null constraint Owner_Type__owner_type_id__PK Primary Key,
	owner_type_tag varchar(5) not null
);

MBG Conf file

<context id="demo" targetRuntime="MyBatis3DynamicSql">
...
<table catalog="fooBar" schema="public" tableName="Owner_Type" domainObjectName="OwnerType">
<generatedKey column="owner_type_id" sqlStatement="Select IDENTITY()" identity="true" type="post" />
<columnOverride column="owner_type_tag" property="ownerTypeTag" javaType="com.foo.bar.AppConstants.OwnerType" />
</table>
</context>

Application Java File

package com.foo.bar;

public interface AppConstants
{
enum OwnerType {PRIMARY, INTEREST, SIGNATURE};
}

MBG generated DynamicSqlSupport (relevant code shown)

import com.foo.bar.AppConstants.OwnerType;
......
public final class OwnerTypeDynamicSqlSupport {
@generated(value="org.mybatis.generator.api.MyBatisGenerator", date="2021-07-11T11:11:39.306227-10:00", comments="Source Table: fooBar.PUBLIC.OWNER_TYPE")
public static final OwnerType ownerType = new OwnerType();
.....
@generated(value="org.mybatis.generator.api.MyBatisGenerator", date="2021-07-11T11:11:39.306823-10:00", comments="Source field: fooBar.PUBLIC.OWNER_TYPE.OWNER_TYPE_TAG")
public static final SqlColumn<OwnerType> ownerTypeTag = ownerType.ownerTypeTag;

@generated(value="org.mybatis.generator.api.MyBatisGenerator", date="2021-07-11T11:11:39.306408-10:00", comments="Source Table: fooBar.PUBLIC.OWNER_TYPE")
public static final class OwnerType extends SqlTable {
.....
public final SqlColumn<OwnerType> ownerTypeTag = column("OWNER_TYPE_TAG", JDBCType.VARCHAR);
.....
}
}

**MBG generated Mapper (showing only one of the methods where errors are reported) **

@generated(value="org.mybatis.generator.api.MyBatisGenerator", date="2021-07-11T11:11:39.31574-10:00", comments="Source Table: fooBar.PUBLIC.OWNER_TYPE")
static UpdateDSL<UpdateModel> updateAllColumns(OwnerType record, UpdateDSL<UpdateModel> dsl) {
   return dsl.set(ownerTypeTag).equalTo(record::getOwnerTypeTag);
}

The reason for the error is because in the OwnerTypeDynamicSqlSupport file the import of the enum class:
import com.foo.bar.AppConstants.OwnerType; is not used. Instead the following lines:
public static final SqlColumn<OwnerType> ownerTypeTag = ownerType.ownerTypeTag;
public final SqlColumn<OwnerType> ownerTypeTag = column("OWNER_TYPE_TAG", JDBCType.VARCHAR);
wrongly reference the generic type of the com.foo.bar.mappers.generated.OwnerTypeDynamicSqlSupport.OwnerType class.

To remove all ambiguity, if we simply rename the static inner class that extends the SqlTable to something different, the errors are all gone. E.g.

Changing From:

public static final class OwnerType extends SqlTable {

TO

public static final class OwnerTypeTable extends SqlTable {

All issues are gone. The following lines now reference the correct enum class instead of the extended SqlTable class
public static final SqlColumn<OwnerType> ownerTypeTag = ownerType.ownerTypeTag;
public final SqlColumn<OwnerType> ownerTypeTag = column("OWNER_TYPE_TAG", JDBCType.VARCHAR);

If the name of the static final inner class is changed to something else, then might i suggest that even the name of the static variable in the DynamicSqlSupport class that references this class, also be named differently. Such a change though not needed to address this issue, would address issues:

1. 724: MyBatis3DynamicSql target runtime causes a name collision warning for tables with identically named columns
2. 620: avoid argument and column name confict

[jeffgbutler]

Thank you for the detailed explanation. This is a difficult problem to solve in all cases because someone could always create something that would cause a name collision.

One relatively easy fix would be as follows:

1. Keep things as they are by default (to avoid breaking existing code)
2. Add a property that would allow a user to specify a value for the generated SqlTable object
3. Use the same name for the variable

For example, something like this

<table tableName="OwnerType">
  <property name="dynamicSqlTableObjectName" value="OwnerTypeTable" />
</table>

And then generate code like this:

public final class OwnerTypeDynamicSqlSupport {
  public static final OwnerTypeTable ownerTypeTable = new OwnerTypeTable();
  ...

  public static final class OwnerTypeTable extends SqlTable {
    ...
  }
}

Also note that this would be different than simply renaming the domain object (which you can do now).

<table tableName="OwnerType" domainObjectName="OwnerTypeTable" />

If you specify a domainObjectName then it impacts everything - the generated record type, the dynamic SQL support class, the mapper name, etc. My proposed new property only impacts the SqlTable object.

What do you think?

This would address #724 also, but I think the issue in #620 might be different. I think #620 is about the fact that we append an underscore to argument names in the methods like "selectByPrimaryKey" - but I may be misunderstanding that issue. Unfortunately the reporter of that issue is no longer on Github so we may never know what they were thinking.

[mahiarmody]

Hello Jeff,
Thank you for the quick reply. Yes, the <property ....> approach that you propose will work perfectly. In fact that is what I had initially though, but then decided with just renaming the static inner class, which extends SqlTable because that would be a quicker fix.

However, the change that you've proposed is a more complete change. It should address all possible use cases.

It would be great if the MyBatis Generator documentation could also be updated to include this new property.

Thank you again.