Yank
Yank copied to clipboard
Replace InsertedIDResultSetHandler with (built-in) ScalarHandler
ScalarHandler<T> is generic, built-in, already in use, and more robust - not limited to one type. Common case to have INT generated primary keys, so the custom class is brittle.
So if I understand this correctly, you would want to pass in Integer
or Long
(or even String
?) to the insert
method and not be forced to receive a Long
?
Sort of. But no need for the type explicitly, it is inferred:
public static <R> R insert(String poolName, String sql, Object[] params) {
try {
return new QueryRunner(getDataSource(poolName)).insert(sql, new ScalarHandler<>(), params);
} catch (SQLException e) {
throw new WrappedSqlException("Error inserting: " + sql, e);
}
}
Of course, that’s using 1.7 type erasure, but the essence of the code works in 1.5 (and hence 1.6) too, just need a cast (and perhaps a @suppresswarnings(“unchecked”)
On Feb 16, 2015, at 10:01 AM, Tim Molter [email protected] wrote:
So if I understand this correctly, you would want to pass in Integer or Long (or even String?) to the insert method and not be forced to receive a Long?
— Reply to this email directly or view it on GitHub https://github.com/timmolter/Yank/issues/23#issuecomment-74548783.
Thanks. I tried this, but using ScalarHandler
, I cannot guarantee which type is returned (int, long) and the cast can go wrong, ending up with a java.lang.ClassCastException
. My InsertedIDResultSetHandler forces it to always be a long.
Presumably of I created the class that's being inserted I'd also know what type to expect for the ID. And if I ain't sure I can also introspect the type.
Flexibility = power.
Rigidity => brittleness and unnecessary limitation.
On Aug 4, 2016, at 2:13 AM, Tim Molter [email protected] wrote:
Thanks. I tried this, but using ScalarHandler, I cannot guarantee which type is returned (int, long) and the cast can go wrong, ending up with a java.lang.ClassCastException. My InsertedIDResultSetHandler forces it to always be a long.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
OK, so your idea was to have the client make the call what type it should be. That makes sense, but I'll need to look at it again to see how to do it. I'll reopen it.