Hi Lukas, I understand your concern for backward compatibility. BTW I already saw your jOOλ work and immediately recognized all the stream operators I have missed from the Streams API :) I may start working with it as my default approach to Streams.
As for use-cases of parellelization, there is really nothing specific to a result set about it: pick your favorite example of computation-intensive processing of a large dataset. Whenever I/O speed overtakes CPU speed, you've got a parallelization target. My specific use case are Lucene queries executed against each row of DB data. The key advantage of a lazy stream is that it turns O(n) space into O(1), making your code scalable to datasets of indefinite size. The stream can either be reduced to some O(1) result, or mapped to an output form which is written directly to an output stream. Regards, Marko On Friday, September 19, 2014 1:15:58 PM UTC+2, Lukas Eder wrote: > > Hi Marko, > > jOOQ currently doesn't support any Java 8 API as we want to maintain > backwards compatibility with Java 6 for our customers. However, with jOOQ > 3.5, we're going to have Cursor extend Iterable (and perhaps also Iterator) > for better interoperability with Java 8 Streams. > > Note that we've also recently published jOOλ (https://github.com/jOOQ/jOOL), > which is an enhancement to the JDK's Stream API, supporting a variety of > convenience methods for purely sequential streams. > > The nice thing about Streams is that the above can be used without further >> ado to parallelize the result set processing. In actual projects I do >> provide my own splitting logic, but that's a relatively minor detail. > > > Interesting. What would be a use-case for parallelised result set > processing? > > Cheers > Lukas > > 2014-09-19 12:42 GMT+02:00 Marko Topolnik <[email protected] > <javascript:>>: > >> I'm working with JOOQ 3.4.1 and don't see any direct support for making a >> lazy Java 8 Stream from JOOQ's Cursor. Is such a thing planned or am I >> missing something already provided? For reference, this is my current >> solution which works for me: >> >> public class JooqResultSpliterator<R extends Record> extends >> AbstractSpliterator<R> >> { >> private final Cursor<R> cursor; >> >> public JooqResultSpliterator(ResultQuery<R> q) { >> super(Long.MAX_VALUE, NONNULL | ORDERED); >> this.cursor = q.fetchSize(50).fetchLazy(); >> } >> >> @Override public boolean tryAdvance(Consumer<? super R> action) { >> final R r = cursor.fetchOne(); >> if (r == null) return false; >> action.accept(r); >> return true; >> } >> >> @Override public void forEachRemaining(Consumer<? super R> action) { >> cursor.fetchInto(action::accept); >> } >> >> public static <R extends Record> Stream<R> jooqStream(ResultQuery<R> q) >> { >> final JooqResultSpliterator<R> s = new JooqResultSpliterator<>(q); >> return StreamSupport.stream(s, false).onClose(s.cursor::close); >> } >> } >> >> The nice thing about Streams is that the above can be used without >> further ado to parallelize the result set processing. In actual projects I >> do provide my own splitting logic, but that's a relatively minor detail. >> >> >> Marko >> > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
