Closed GoogleCodeExporter closed 9 years ago
Ah, thanks for tihs... I wasn't sure what the underlying problem was, my
workaround was to write the sql queries like this:
'${enumVar}' preventing it from showing up as a param in a PreparedStatement,
as opposed to #{enumVar}
Original comment by alex.she...@gmail.com
on 22 Sep 2010 at 12:48
I think an acceptable work-around for this is to define you're own
EnumTypeHandler that does this.
I am not against using OTHER as the JDBC type, but the actual JDBC type will
probably vary depending on the database. So using OTHER for everybody may cause
problems.
Original comment by christia...@ircm.qc.ca
on 17 Dec 2010 at 1:33
Original comment by christia...@ircm.qc.ca
on 17 Dec 2010 at 1:34
What about introducing JdbcType.ENUM and in then setNonNullParameter only using
java.sql.Types.OTHER when jdbcType == JdbcType.ENUM ?
Original comment by herman.b...@gmail.com
on 13 Jan 2011 at 4:45
Using OTHER as JDBC type does not work for some databases.
I've changed the code so that VARCHAR is the default, but if you specify OTHER
as the JDBC type, it will be set correctly.
Can you check if it works?
The new code for EnumTypeHandler is
public void setNonNullParameter(PreparedStatement ps, int i, Object parameter, JdbcType jdbcType) throws SQLException {
if (jdbcType == null) {
ps.setString(i, parameter.toString());
} else {
ps.setObject(i, parameter.toString(), jdbcType.TYPE_CODE);
}
}
Original comment by christia...@ircm.qc.ca
on 26 Jan 2011 at 3:15
Since I didn't have any feedback since the last 2 months, I'll consider this
bug to be fixed.
Original comment by christia...@ircm.qc.ca
on 15 Apr 2011 at 12:52
Original comment by eduardo.macarron
on 3 Mar 2012 at 9:11
Original comment by eduardo.macarron
on 3 Mar 2012 at 9:13
Original issue reported on code.google.com by
megamanf...@gmail.com
on 14 Sep 2010 at 8:41