Re: Mass data batch processing

2017-03-02 17:13 GMT+01:00 Mike Foody : > Once JOOQ has a Java9 dependency that'd be great. In the meantime most of > these libraries have convenicen APIs for this purpose. For instance to > convert that stream into an RxJava observable is just >

Re: Mass data batch processing

Once JOOQ has a Java9 dependency that'd be great. In the meantime most of these libraries have convenicen APIs for this purpose. For instance to convert that stream into an RxJava observable is just Observable.from(jooqStream::iterator). It'd be nicer to say fetchIntoObservable but not much nicer

Re: [REQUEST FOR FEEDBACK]: What small but incredibly useful utility are you missing the most in jOOQ?

That sounds very interesting. Indeed, if you remove UD from CRUD, things do get much simpler. Would be very curious to see that in action! 2017-03-02 13:31 GMT+01:00 : > We've solved writing back entity graphs a bit differently. The application > has a requirement for

Re: Mass data batch processing

Yes, indeed, an Observer might be a better way to abstract over a stream of data to merge into different target tables. It would certainly work with a Java 8 stream as well, but maybe this feature request might just be a good enough reason to embrace what appears to become a new de-facto standard

Re: Mass data batch processing

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

Re: Keys, fields, values and generics

Thank you very much for sharing your thoughts, Thomas. 2017-02-27 10:57 GMT+01:00 Thomas GILLET : > Hello all, > > Happily using jOOQ for a while now, I'm starting to use it for a little > more than just SQL generation and I'm struggling a little when working with >

Re: [REQUEST FOR FEEDBACK]: What small but incredibly useful utility are you missing the most in jOOQ?

We've solved writing back entity graphs a bit differently. The application has a requirement for business process purposes as well as compliance reasons to maintain a complete history of all changes. We've chosen to support this using a bi-temporal data model. Almost every table in the

Re: [REQUEST FOR FEEDBACK]: What small but incredibly useful utility are you missing the most in jOOQ?

Btw: This was published just now: https://arnaudroger.github.io/blog/2017/03/02/jooq-one-to-many-without-dto.html Here's the author: https://twitter.com/arnaudroger 2017-03-02 12:58 GMT+01:00 Lukas Eder : > Hi Thomas, > > Thank you very much for your detailed elaborations,

Re: [REQUEST FOR FEEDBACK]: What small but incredibly useful utility are you missing the most in jOOQ?

Hi Thomas, Thank you very much for your detailed elaborations, greatly appreciated! 2017-02-28 16:51 GMT+01:00 Thomas GILLET : > Hi Lukas, > > Just to get the complete picture [...] What currently keeps you from using >> JPA? > > > A long time ago, I used to use JPA to

Re: Mass data batch processing

2017-03-01 23:14 GMT+01:00 Jan Lessner : > > 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

Re: Postgres - suspected minor missing functionality

Hello, Thanks for your messages. Indeed, these are known limitations of jOOQ version 3.9, which will be fixed in version 3.10: - ON CONFLICT .. RETURNING: #2123 - ON CONFLICT .. WHERE: #5637 ON