This is how SQL should have been used all along. They called it The Third Manifesto, ORDBMS, or other things. Regrettably, it never really took off. Because most vendors didn't adopt it. And those who did, didn't agree on syntax. But this is about to change. Thanks to the now ubiquitous SQL/JSON support (which jOOQ … Continue reading jOOQ 3.15’s New Multiset Operator Will Change How You Think About SQL
Use ResultQuery.collect() to Implement Powerful Mappings
In our opinion, any Iterable<T> should offer a <R> collect(Collector<T, ?, R>) method to allow for transforming the the content to something else using standard JDK collectors, jOOλ collectors from org.jooq.lambda.Agg or your own. When using jOOQ, you don't have to wait for the JDK to finally add these useful utilities to the Iterable API. … Continue reading Use ResultQuery.collect() to Implement Powerful Mappings
Could we Have a Language That Hides Collections From Us?
I just fixed a bug. The fix required me to initialise an Object array with the init values for each type, instead of just null, i.e. false for boolean, 0 for int, 0.0 for double, etc. So, instead of just doing: Object converted = new Object[parameterTypes.length]; I needed: Object converted = new Object[parameterTypes.length]; for (int … Continue reading Could we Have a Language That Hides Collections From Us?
A Quick Trick to Make a Java Stream Construction Lazy
One of the Stream APIs greatest features is its laziness. The whole pipeline is constructed lazily, stored as a set of instructions, akin to a SQL execution plan. Only when we invoke a terminal operation, the pipeline is started. It is still lazy, meaning that some operations may be short circuited. Some third party libraries … Continue reading A Quick Trick to Make a Java Stream Construction Lazy
How to Write a Simple, yet Extensible API
How to write a simple API is already an art on its own. I didn't have time to write a short letter, so I wrote a long one instead. ― Mark Twain But keeping an API simple for beginners and most users, and making it extensible for power users seems even more of a challenge. … Continue reading How to Write a Simple, yet Extensible API
How to Unit Test Your Annotation Processor using jOOR
Annotation processors can be useful as a hacky workaround to get some language feature into the Java language. jOOQ also has an annotation processor that helps validate SQL syntax for: Plain SQL usage (SQL injection risk) SQL dialect support (prevent using an Oracle only feature on MySQL) You can read about it more in detail … Continue reading How to Unit Test Your Annotation Processor using jOOR
Imperative Loop or Functional Stream Pipeline? Beware of the Performance Impact!
I like weird, yet concise language constructs and API usages https://twitter.com/nipafx/status/1055451667079008256 Yes. I am guilty. Evil? Don't know. But guilty. I heavily use and abuse the java.lang.Boolean type to implement three valued logic in Java: Boolean.TRUE means true (duh) Boolean.FALSE means false null can mean anything like "unknown" or "uninitialised", etc. I know - a … Continue reading Imperative Loop or Functional Stream Pipeline? Beware of the Performance Impact!
How to Write a Multiplication Aggregate Function in SQL
Everyone knows the SQL SUM() aggregate function (and many people also know its window function variant). When querying the Sakila database, we can get the daily revenue (using PostgreSQL syntax): WITH p AS ( SELECT CAST (payment_date AS DATE) AS date, amount FROM payment ) SELECT date, SUM (amount) AS daily_revenue, SUM (SUM (amount)) OVER … Continue reading How to Write a Multiplication Aggregate Function in SQL
How to Patch Your IDE to Fix an Urgent Bug
Clock's ticking. JDK 11 will remove a bunch of deprecated modules through JEP 320, which includes the Java EE modules, which again includes JAXB, a dependency of many libraries, including jOOQ. Thus far, few people have upgraded to Java 9 or 10, as these aren't LTS releases. Unlike in the old days, however, people will … Continue reading How to Patch Your IDE to Fix an Urgent Bug
Truth First, or Why You Should Mostly Implement Database First Designs
In this much overdue article, I will explain why I think that in almost all cases, you should implement a "database first" design in your application's data models, rather than a "Java first" design (or whatever your client language is), the latter approach leading to a long road of pain and suffering, once your project … Continue reading Truth First, or Why You Should Mostly Implement Database First Designs