GitHub user mdedetrich added a comment to the discussion: reduce or remove use of Scala Futures in favour of sticking to reactive streams
Its not that Future is bad and Stream is good, its that one abstraction is a less powerful but simple one (`Future`) and the other one is much more complicated but more powerful (`Stream`). For this specific usecase, we already have a `Stream` from the core projection interface, if we didn't the calculus of the argument would be completely different. Going from stream -> materialize into future -> back into stream is at best pointless and at worst harmless since you can lose all benefits of the stream. For an adapter like JDBC using `Future` makes sense as JDBC has no concept of streaming (or any of the other projection adaptors at a quick glance), but for R2DBC you lose almost the entire point of R2DBC in the first place and R2DBC is the exception here since its pure streaming. Of course we can speculate what the reasons were, it might have just been a case of "we already had postgres-jdbc and the quickest way to write an R2DBC would be to use postgres-jdbc as a base implementation". GitHub link: https://github.com/apache/pekko-persistence-r2dbc/discussions/265#discussioncomment-14917228 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
