4 ms·

Never heard of this before as I mainly use MS stack. However, my first impression is very positive. 1. Database First Great way to distinguish your product f

Never heard of this before as I mainly use MS stack. However, my first impression is very positive. 1. Database First Great way to distinguish your product from traditional ORMs. I am personally not a fan of code first approach especially as a LOB applications developer. I have been writing code for 15 years and the database/schema has outlived each and every application that I wrote. (I am in full agreement with lukaseder's comment: https://news.ycombinator.com/item?id=10880942 https://news.ycombinator.com/item?id=10880942) As an experienced developer, they immediately made their value proposition clear to me and I wanted to learn more. 2. Examples Side by side example comparing jOOQ to SQL. A great way for me to quickly see if I like their DSL design. 3. Convince your manager page. I absolutely loved this: http://www.jooq.org/why-jOOQ.pdf http://www.jooq.org/why-jOOQ.pdf 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.

habitue 11y ago
I came across JooQ when looking for LINQ in Java. I believe that's the original inspiration
- cwyers 11y ago
  I mean, the JOOQ guys all seem to hate the hell out of LINQ for abstracting the query language across data stores.
hiram112 11y ago
>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!
lawpoop 11y ago
> 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.
- pbowyer 11y ago
  > 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/ http://www.pomm-project.org/ ?
moron4hire 11y ago
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.

habitue 11y ago

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

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

hiram112 11y ago

>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!

lawpoop 11y ago

> 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.

pbowyer 11y ago
> 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/ http://www.pomm-project.org/ ?

moron4hire 11y ago

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.