开发者

What is supposed to happen in ResultSet#next with the cursor on the insert row?

开发者 https://www.devze.com 2023-02-08 16:21 出处:网络
I\'m a bit at a loss here. I\'m supposed to write an implementation of javax.sql.RowSet for a specific purpose and I\'m trying to unit-test it as well as far as I can.

I'm a bit at a loss here. I'm supposed to write an implementation of javax.sql.RowSet for a specific purpose and I'm trying to unit-test it as well as far as I can.

Now, a ResultSet has a cursor that can be on a normal row (or before the first or after the last) or on the insert row. moveToInsertRow() says:

Only the updater, getter, and insertRow methods may be called when the cursor is on the insert row.

Nothing is said on what is supposed to happen then. next() is less helpful by not even pointing that case out:

Moves the cursor forward (sic!) one row from its current position. A ResultSet cursor is initially positioned before the first row; the first call to the method next makes the first row the current row; the second call makes the second row the current row, and so on.

When a call to the next method returns false, the cursor is positioned after t开发者_StackOverflow社区he last row. Any invocation of a ResultSet method which requires a current row will result in a SQLException being thrown. If the result set type is TYPE_FORWARD_ONLY, it is vendor specified whether their JDBC driver implementation will return false or throw an SQLException on a subsequent call to next.

If an input stream is open for the current row, a call to the method next will implicitly close it. A ResultSet object's warning chain is cleared when a new row is read.

Returns:

true if the new current row is valid; false if there are no more rows

Throws:

SQLException - if a database access error occurs or this method is called on a closed result set

I have no prior experience with the JDBC APIs and therefore have no clue whether that's intentionally unspecified (undefined behavior maybe?) or just an oversight.

Currently I think I'd just throw an SQLException even though that's nowhere specified and thus maybe UnsupportedOperationException would be better (as SQLException signals a DB error or a closed ResultSet – neither of which would be the case here).

Or did I just miss a bit of documentation somewhere?


I suggest you follow the contract of moveToInsertRow() and throw some sort of exception (SQL- or IllegalState-). This is going to cause the least trouble if people mistakenly call next().

You could also have a look at others' implementation to see what they do (MySQL Connector/J for example) so that other frameworks you use won't get surprised.


How about just writing a small program to actually test the behavior of next() after moveToInsertRow()?

I'm a TDDer but sometimes when I'm programming something that uses a "foreign" API I would create a small proof of concept that is not really test driven, usually called a "spike", that way I can learn how the different API calls interact. When I feel like I have a good grasp of the API I just throw the spike away and start coding in normal TDD fashion.

0

精彩评论

暂无评论...
验证码 换一张
取 消