Java and databases are my professional passion. When they work together, great software can evolve. Many proprietary and standard ideas have been around to make them work together. I feel that there is yet one missing piece gluing them together more intuitively. That's why I created jOOQ:
jOOQ effectively combines complex SQL, typesafety, source code generation, active records, stored procedures, advanced data types, and Java in a fluent, intuitive DSL.
Submissions
Transpile any SQL dialect to any SQL dialect (not just to PostgreSQL)
jooq.org
3 points·by lukaseder··0 comments
Working with JOOQ and Flyway Using Testcontainers
testcontainers.com
1 points·by lukaseder··0 comments
How to plot an ASCII bar chart with SQL
blog.jooq.org
1 points·by lukaseder··0 comments
Various meanings of SQL’s PARTITION BY syntax
blog.jooq.org
1 points·by lukaseder··0 comments
Use SQL multiset predicates to compare data sets
blog.jooq.org
2 points·by lukaseder··0 comments
Fun with PostGIS: Mandelbrot set, game of life, and more
blog.jooq.org
28 points·by lukaseder··0 comments
What my Stackoverflow addiction did to my career
blog.lettucework.io
4 points·by lukaseder··0 comments
PostgreSQL 14's enable_memoize for improved performance of nested loop joins
blog.jooq.org
14 points·by lukaseder··0 comments
Write C-style local static variables in Java 16
blog.jooq.org
1 points·by lukaseder··0 comments
Standard SQL/JSON – the sobering parts
blog.jooq.org
1 points·by lukaseder··0 comments
Reactive SQL with JOOQ 3.15 and R2DBC
blog.jooq.org
1 points·by lukaseder··0 comments
JOOQ 3.15’s New Multiset Operator Will Change How You Think About SQL
blog.jooq.org
2 points·by lukaseder··0 comments
Thinking in Questions with SQL
benjiweber.co.uk
4 points·by lukaseder··0 comments
The myth of NoSQL (vs. RDBMS) agility
blog.dbi-services.com
15 points·by lukaseder··2 comments
Build a Java App with CockroachDB and JOOQ
cockroachlabs.com
2 points·by lukaseder··0 comments
Java Database Access: An Overview Guide
marcobehler.com
2 points·by lukaseder··0 comments
PostgreSQL 11 support for SQL standard GROUPS and EXCLUDE window function clause
blog.jooq.org
2 points·by lukaseder··0 comments
The informational ecosystem of net neutrality
internet-regulation.org
1 points·by lukaseder··0 comments
Finding all palindromes contained in strings with SQL
blog.jooq.org
1 points·by lukaseder··0 comments
Avoiding burnout or lessons learned from six years as an independent consultant
Informix also supports MULTISET natively. Many others support ARRAY, which is equivalent for all practical purposes. jOOQ popularised MULTISET over ARRAY because the existing ARRAY support was less user friendly, mapping results to actual Java array types.
Not sure what you mean. I meant that without declaration site variance, ("pragmatic") unsafe casting is everywhere in jOOQ's internals. Without being able to capture wildcards in local type variables, ("pragmatic") rawtypes are everywhere as well (check Collections.swap() for an illustration)
jOOQ doesn't get involved in any such prefetch/eager fetch shenanigans, which are often wrong. They work for some cases and do too little/too much for others. So, specifying the exact data to fetch in every query is a much better approach, ideally with nested collections:
https://blog.jooq.org/jooq-3-15s-new-multiset-operator-will-...
> Not sure how successful jOOQ has been financially, but considering they've been around for many years at this point, I have to imagine it's worked out well enough to pay for the lights and kibble?
I don't know if your various flatMap / etc methods are purely implemented in the client (it would be quite bad from a performance perspective? But since you're implementing reducers in kotlin, I guess that's what this is), or if you somehow translate the AST to SQL (similar to jinq.org in Java or Slick in Scala or LINQ in .NET).
But in either case, I think that mimicking "idiomatic" client APIs is more of a distraction than something useful. I've explored this here, where I was asked about my opinion on Kotlin's Exposed:
https://www.youtube.com/watch?v=6Ji9yKnZ3D8
Obviously, this is ultimately a matter of taste, but just like all these "better SQL languages" (e.g. PRQL) come and go, these translations to "better APIs" also come and go. SQL is the only thing to stay (has been for more than 50 years now!)
> We could add parallelism with a .parallelStream() in the right spot easily enough
You typically don't even need to hint it, the optimiser might choose to parallelise on its own, or not, depending on production load... Anyway, that's an overrated topic, IMO.
> I think you probably overestimate how easy SQL is because you're an expert in it.
I'm happy when coding in any language / paradigm. When working with XML, I will happily use XSLT, XPath, etc. When working with JSON, I don't mind going into JavaScript. I'm just trying to stay curious.
I really don't think that SQL is "harder" than any other language. It may just be something certain people don't really like, for various reasons.
> Your whole product is built on the fact that SQL isn't good enough
I think you're projecting your own distaste into my work here. I love SQL. SQL is wonderful. It's quirky, yes, but what isn't. jOOQ users just don't like working with an external DSL within Java (though many are very happy to write views and stored procedures with SQL and procedural extensions). There's no need for a false dichotomy here. I've worked on large systems that were mostly implemented with SQL written in views, and it was perfect!
Also, jOOQ is much more than just the DSL. SQL transformation, parsing, etc., it's a vast product. The string-y SQL folks could use it as a template engine, without touching the DSL, and still profit from parsing / transformations / mapping:
https://blog.jooq.org/using-java-13-text-blocks-for-plain-sq...
Some customers use jOOQ merely to migrate off Oracle to PostgreSQL (via the translating JDBC proxy).
And I'm looking forward to the OpenJDK's Project Babylon. Perhaps we'll get actual macros in Java, soon, which could work well with jOOQ.
Anyway, I didn't mean to hi-jack too much. It's great when people try out new / different approaches. I'm just triggered whenever someone claims that SQL is harder than anything else, when they should have said, they prefer other things and don't want to learn more SQL (which is fine, but quite a different statement).
The "object oriented" in jOOQ Object Oriented Querying stands for an object oriented query model, not mapping to object oriented target data structures.
SQL is powerful. A DSL that "fixes" things in this area getting all the other language feature interactions right isn't trivial, all the while users have to learn yet another language. Take PRQL for example: https://prql-lang.org. It looks nice, but the examples are very basic. What about window functions, grouping sets, lateral, DML, recursive SQL, pattern matching, pivot/unpivot etc. Might be doable, but perhaps, they've already made a decision that won't enable one of those features without adding new kludges.
Besides, every single "fix" will be a proprietary solution, while SQL is an ISO/IEC standard that's here to stay and universally adopted.
> A good DSL can do much better.
Stonebraker's QUEL was "better", before SQL, and yet, where is QUEL today?
> There are tradeoffs everywhere though, so with Jooq you still aren't 1-to-1 with raw SQL
You're probably hinting at writing derived tables / CTEs? jOOQ will never keep you from writing views and table valued functions, though. It encourages you do so! Those objects play very well with code generation, and you can keep jOOQ for the dynamic parts, views/functions for the static parts.
jOOQ effectively combines complex SQL, typesafety, source code generation, active records, stored procedures, advanced data types, and Java in a fluent, intuitive DSL.