Enhancements to ResultIterable #2056

spannm · 2022-06-11T12:16:14Z

Add method ResultIterable#filter to apply a filter (predicate) to a result iterable without use of streams.
Similarities with ResultIterable#map extracted into class ResultIteratorDelegate
Add enhanced ResultIterable#forEachWithCount, an enhanced forEach method that returns the iteration/record count
Add unit tests

stevenschlansker · 2022-06-13T18:11:12Z

Hi @sman-81 , could you share a bit about what use case you expect for these new features? In particular, we avoid doing filter in Java code, since the predicate cannot be lifted up to the database.
And, if you want to do more in-Java processing, we would encourage you to .stream() the results, and then you get much more powerful / flexible processing "for free" without Jdbi modifications.

spannm · 2022-06-14T05:46:15Z

Hi @stevenschlansker,

thanks for your feedback!

We avoid switching to Stream for 'intermediate' operations and stay within the ResultIterable type to perform custom, value-added 'terminal' operations such as forEachWithCount.
Frequently working with resultsets and Jdbi one will do forEach to iterate over the resultset (doing this does not use Stream API).
Along the same lines, the map, findOne, first, findFirst methods, which all have existed for a long time, do not use Stream API. My new filter method works along those lines.

In particular, we avoid doing filter in Java code, since the predicate cannot be lifted up to the database.

What do you mean?
filter could be done in most if not all dbms using WHERE.
Similarly map could be done inside db using built-in functions.

Yet, having both in JDBI serves a very good purpose, as it allows you to keep a db simple and shift more complex processing to Java.

spannm · 2022-06-20T16:42:00Z

Hi @stevenschlansker,

Hope this finds you well :)
I am rather excited about the positive impact of this PR.
Could you kindly get back to me on my above comments?

Cheers, Markus

stevenschlansker

Ok. I am still slightly concerned that newbie users would mistake that filter somehow operates efficiently, when it actually precludes letting the database do the heavy lifting.
Perhaps we could add a note to the Javadoc to make it clear that results must be loaded into Java and then thrown away, which means e.g. that indexes cannot be used.
Otherwise people might incorrectly assume that we have LINQ-like features which actually can magically do this.

I left some comments on the implementation. Let me know what you think.

core/src/main/java/org/jdbi/v3/core/result/ResultIterable.java

core/src/test/java/org/jdbi/v3/core/statement/TestQueries.java

stevenschlansker · 2022-06-27T21:22:41Z

And sorry for the delay @sman-81 , I have been on vacation 🌴

Add method ResultIterable#filter to apply a filter (predicate) to a result iterable without use of streams. Similarities with ResultIterable#map extracted into class ResultIteratorDelegate Add enhanced ResultIterable#forEachWithCount, an enhanced forEach method that returns the iteration/record count Add unit tests Incorporate feedback from Steven