Add lenientString to SqlRow #84
Conversation
| * Like [[stringOption]], but calls `getString` instead of `getObject`, so may | ||
| * convert other types into Strings, depending on the driver. | ||
| */ | ||
| def lenientStringOption(column: String): Option[String] = getResultSetOption(resultSet.getString(column)) |
There was a problem hiding this comment.
Isn't this the same as strictString and strictStringOption?
tmccombs
force-pushed
the
lenient-string
branch
3 times, most recently
from
01676c1 to
1eaab4b
Compare
| def strictString(column: String): String = resultSet.getString(column) | ||
| def strictStringOption(column: String): Option[String] = getResultSetOption(resultSet.getString(column)) | ||
| def strictString(column: String): String = string(column) | ||
| def strictStringOption(column: String): Option[String] = stringOption(column) |
There was a problem hiding this comment.
I'd flip this personally. Have stringOption call through to strictStringOption rather than the other way around.
If 'strict' represents "matching the behavior from the ResultSet directly", and 'standard' methods represent 'the interface we want', then it makes sense for strictString to call the resultSet, and it make sense of stringOption to say "the behavior we want matches the ResultSet behavior"
| @@ -73,8 +73,8 @@ class SqlRow(val resultSet: java.sql.ResultSet) extends ResultSetWrapper { | |||
| def strictShortOption(column: String): Option[Short] = getResultSetOption(resultSet.getShort(column)) | |||
| def strictSQLXML(column: String): SQLXML = resultSet.getSQLXML(column) | |||
| def strictSQLXMLOption(column: String): Option[SQLXML] = getResultSetOption(resultSet.getSQLXML(column)) | |||
| def strictString(column: String): String = resultSet.getString(column) | |||
| def strictStringOption(column: String): Option[String] = getResultSetOption(resultSet.getString(column)) | |||
| def strictString(column: String): String = string(column) | |||
There was a problem hiding this comment.
We are changing strictString to get the "throw NoSuchElementExceptionbehavior, rather thannullor0`. Why aren't we changing strictLong as well? (Again, this is why I'd 'flip' the implementation of strictString and strictStringOption back)
There was a problem hiding this comment.
Oh, I meant to undo that change.
Instead of calling getObject and inspecting the type. This makes the parsers more consistent. And restores the previous behavior of ColReaders. This makes it so longOption, bigDecimalOption, and stringOption, etc. may not throw exceptions in cases where it did before. But I think this is probably the behavior that would be expected.
tmccombs
force-pushed
the
lenient-string
branch
from
1eaab4b to
0d6e141
Compare
And use it for ColReader to restore previous behaviour