Actually an interesting idea. It may allow to build such a pipeline *on top* of JOOQ using DSLContext.batchInsert and DSLContext.batchUpdate on the subscriber side.
I will check that out until Lucas builds in the Java 9 flow support ;-) Am Donnerstag, 2. März 2017 14:28:23 UTC+1 schrieb [email protected]: > > Please excuse me if I misunstand the requirements. You want to process the > stream of data and collect it into inserts into the contact history table > and updates to the email address and then batch process these once you've > collected enough to make the batch efficient. The pain is that Java streams > aren't easily split and don't provide an API to deal with the window > functionality. You might take a look at RxJava. You could create an RxJava > observable from your stream of data with multiple subscribers. One > subscriber would filter the stream looking for inserts, the other for > updates. You could then use the built-in window functionality to collect > inserts / updates until you have the number needed for efficiency. Here's a > couple links that flesh this out. > > http://blog.danlew.net/2016/06/13/multicasting-in-rxjava/ > > http://stackoverflow.com/questions/25165520/rxjava-window-on-count-or-timespan-without-dropping-elements > > > On Thursday, March 2, 2017 at 4:31:22 AM UTC-6, Lukas Eder wrote: >> >> >> >> 2017-03-01 23:14 GMT+01:00 Jan Lessner <[email protected]>: >>> >>> The reason for using an Exadata is not the Java-based operative system >>> but the analytical data warehouse. But we are currently in preparation for >>> a massive redesign to expand the business, and we will probably split the >>> analytical and operative database so that the Exadata is no longer our >>> basis. >>> >> >> Yes, that's never a bad idea. Combining OLTP and OLAP in a single system >> works only "for so long" i.e. until you grow to some size. >> >> I've created a feature request for this: >>>> https://github.com/jOOQ/jOOQ/issues/5930 >>>> >>> Thanks a lot. Maybe we can help in the future :-) >>> >> >> You definitely can: The more details we know about your use-case and the >> features you'd like to see, the better this feature will get. >> >> Out of curiosity: What's your development database? >>>> >>> At the moment the developers are working on locally installed Oracle >>> XEs. But in case we moved to JOOQ (coming from PriDE) we would probably >>> change that to make use of JOOQ's open source edition. As we have almost no >>> Oracle-specific aspects in our code, we could dare to use different >>> databases in development and production. >>> >> >> I see, indeed Oracle XE is quite compatible with SE and EE, at least from >> a developer perspective. However, I generally recommend not using a >> database for development that you're not also targeting for production >> systems. There are a lot of differences, e.g. in transaction models and in >> many subtle differences of behaviour that are not covered / abstracted in >> the SQL language per se. >> >> In recent years, Oracle has made working with its database really easy >> for developers by providing out-of-the-box docker images for Oracle 11g and >> 12c: >> https://github.com/oracle/docker-images/tree/master/OracleDatabase >> >> Just a thought :) >> Lukas >> > -- 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.
