jdbi: Streams don't quite make up for v2's Query.fold

In the process of converting my v2 project to v3, I’ve repeatedly found myself wishing to have Query.fold back–or something similar to it.

When we removed it, the idea was that Java 8 streams would fill the niche. They’re very handy, but not all use cases are served by it. In particular:

  • For model-based folds (JoinRowMapper is great for this), Stream.reduce(U, BiFunction<U,T,U>, BinaryOperator<U>) does the job, but the BinaryOperator parameter is pointless, since this is not a parallel stream. This is one instance where I think the JDK over-engineered streams for parallelism, which hurts usability for sequential streams.
  • We still need a fold with raw access to the raw ResultSet. Not all use cases fit in the map-reduce approach.

I propose we add the following API:

@FunctionalInterface
interface ResultSetAccumulator<U> {
    U reduce(U identity, ResultSet rs, StatementContext ctx);
}

class Query {
    ...
    <U> U reduce(U identity, ResultSetAccumulator<U> accumulator);
    <U> U reduce(U identity, BiFunction<U, T, U> accumulator);
}

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 1
  • Comments: 17 (14 by maintainers)

Commits related to this issue

Most upvoted comments

Hmm… we could probably cheat and just map to a ResultSet/context pair, then wrap the ResultSetAccumulator in a BiFunction that catches and rethrows SQLExceptions. Oh my god that looks like complete nonsense without context.

I guess ResultBearing is a better home for the new methods.