Message Title

The issue is mainly a problem with JDBC drivers and implementations of java.sql.ResultSetMetaData#getColumnType / java.sql.ParameterMetaData#getParameterType which we use to make the named/ordinal decision when we do not have enough information in the mapping.

The proposal here is to make the initial resolution during org.hibernate.type.EnumType#setParameterValues be the one and only resolution for named/ordinal (ultimately falling back to ordinal most likely to be consistent with annotations).

public void setParameterValues(Properties parameters) {
    final ParameterType reader = (ParameterType) parameters.get( PARAMETER_TYPE );

    if ( reader != null ) {
        // we are handling annotations case
        ...
    }
    else {
        // hbm.xml case
        this.enumValueMapper = interpretParameters( parameters );
        this.sqlType = enumValueMapper.getSqlType();
    }
}

private EnumValueMapper interpretParameters(Properties parameters) {
    if ( parameters.containsKey( NAMED ) ) {
        final boolean useNamed = ConfigurationHelper.getBoolean( NAMED, parameters );
        if ( useNamed ) {
            return new NamedEnumValueMapper();
        }
        else {
            return new OrdinalEnumValueMapper();
        }
    }

    if ( parameters.containsKey( TYPE ) ) {
        final int type = Integer.decode( (String) parameters.get( TYPE ) );
        if ( isNumericType( type ) ) {
            return new OrdinalEnumValueMapper();
        }
        else if ( isCharacterType( type ) ) {
            return new OrdinalEnumValueMapper();
        }
        else {
            log.debugf( "Passed JDBC type code [%s] not recognized as numeric nor character", type );
        }
    }

    // the fallback
    return new OrdinalEnumValueMapper();
}