Hacker News Reader

> Side by side example comparing jOOQ to SQL. A great way for me to quickly see if I like their DSL design.

I'm always astounded how many times this is neglected. It seems pandemic.

I live in the PHP world, and it seems that every hot new framework wants to do its own SQL re-hash. They always seem created by programmers who either hate SQL and want to avoid it as much as possible in favor of OO paradigms, or have never used it beyond its basic features.

Sooner or later, I'll find myself wanting to do something moderately complex, like delete through a join, and all of a sudden the interface breaks down. I'll scour the internet or ask a question, and it either can't be done, or relies on some arcane, poorly documented part of the API, or uses weird, unintuitive syntax that makes you wonder if the API is any improvement over plain SQL at all.

> I live in the PHP world, and it seems that every hot new framework wants to do its own SQL re-hash. They always seem created by programmers who either hate SQL and want to avoid it as much as possible in favor of OO paradigms, or have never used it beyond its basic features.

Agreed.

I don't use PostgreSQL and haven't got my head around it fully, but have you seen http://www.pomm-project.org/ ?

I came across JooQ when looking for LINQ in Java. I believe that's the original inspiration

I mean, the JOOQ guys all seem to hate the hell out of LINQ for abstracting the query language across data stores.

On your point #1, I personally believe that the correct solution is to treat application code as yet another target for your schema state, and all issues of deployment are just synchronization between two different states. So it's "database first" if you make the database the master state in the sync, or "code first" if you make the C# or Java or whatever code the master state in a particular sync. It doesn't ever have to be set in stone (like EF does). Indeed, there is a certain rapidity of iteration early in the project if you can go back and forth, using different tools at different stages that might edit code, might edit schema, and just be able to sync the two when you're done.

>We all have worked with 'a technical manager' who isn't really technical. When you need to purchase a tool, you need to convince your manager and this page is as good as I have seen. All commercial software development tool product websites should feature a 'Convince your manager' page.

Agreed. The electrical metaphors and accompanying images are marketing gold!