Lazy iteration over JDBC ResultSet

[eric-maynard]

In DatasourceOperations.executeSelect, we currently return a List after copying the entire ResultSet into a List. We provide a few arguments so the caller can supply a limit, a transformer, and a filter.

Instead, we can let the caller provide a Consumer over an Iterator / Stream of the data, keeping the logic in DatasourceOperations strictly persistence-related and affording the caller greater flexibility.

This will help in #273 so we can push the page token down into the query but still do client filtering without having to make a copy of the entire ResultSet.

[singhpk234]

Thank you so much for this improvement @eric-maynard !

[singhpk234]

is there a way to do toList() ?

[eric-maynard]

With the loan pattern, we aren't returning anything so we need to get the list as a side effect. Unfortunately, there is a restriction in Java that variables pulled in to the scope of a lambda must be "effectively final", so we can't do like results = ...toList() in the lambda

[singhpk234]

interesting, if it's a SQLException shouldn't we throw it as SQLException to inspect the error code ? any other exception other than SQLException is considered as RTE for now in the caller.

[eric-maynard]

So the real problem here is ResultSetIterator.next(), which can't throw an exception so long as we're implementing Iterator.

For now I'll have the constructor throw a SQLException so we have a chance of finding a SQLException, but we'd still wrap SQLExceptions that happen after the first ResultSet.next() call. If that's an issue, we can move away from implementing Iterator or fix the caller to unwrap the exception.

[singhpk234]

LGTM !