JOOQ equivalent in Go

[Ben Hood]

Hi Lukas,

I was wondering whether you've come across anything vaguely JOOQ-esque
for Golang. I've used squel.js in some node projects (not saying
that's it's even 5% as rich as JOOQ, but at least it kind of works for
simple stuff). But all of the Go run ups I've come across seem either
tied into an ORM or lean too heavily on string building at the
application level. Have you come across any JOOQ lookalike for Go?

Cheers,

Ben

[Lukas Eder]

Hi Ben,

The only jOOQ-esque API that I'm aware of in Go is CQLC. Written by... you! :-)

http://relops.com/blog/2014/01/25/cqlc

Apart from that, I'm not aware of any other DSLs implementing SQL in Go. If you discover any, I'd be curious to know. What have you found so far?

Cheers

Lukas

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Hood]

Hi Lukas,

On Mon, Sep 22, 2014 at 7:58 AM, Lukas Eder <lukas...@gmail.com> wrote:
> Hi Ben,
>
> The only jOOQ-esque API that I'm aware of in Go is CQLC. Written by... you!
> :-)
> http://relops.com/blog/2014/01/25/cqlc

Thanks for the heads up :-)

But I was looking for something for SQL, not Cassandra.

> Apart from that, I'm not aware of any other DSLs implementing SQL in Go. If
> you discover any, I'd be curious to know. What have you found so far?

The two things I have found so far are:

https://github.com/lann/squirrel
https://github.com/braindev/squiggle

squirrel is more mature than squiggle, but I don't think it addresses
the issue of composeability. squiggle purports to address this, but it
looks like quite early days for it.

Basically I was trying to stop myself from trying to re-invent this
wheel by myself for Go.

Cheers,

Ben

[Lukas Eder]

2014-09-22 9:09 GMT+02:00 Ben Hood <0x6e...@gmail.com>:

Hi Lukas,

On Mon, Sep 22, 2014 at 7:58 AM, Lukas Eder <lukas...@gmail.com> wrote:
> Hi Ben,
>
> The only jOOQ-esque API that I'm aware of in Go is CQLC. Written by... you!
> :-)
> http://relops.com/blog/2014/01/25/cqlc

Thanks for the heads up :-)

But I was looking for something for SQL, not Cassandra.

I know. Well, the query languages essentially work the same way. I just guess that SQL is a lot more work than CQL, though.

 

> Apart from that, I'm not aware of any other DSLs implementing SQL in Go. If
> you discover any, I'd be curious to know. What have you found so far?

The two things I have found so far are:

https://github.com/lann/squirrel
https://github.com/braindev/squiggle

squirrel is more mature than squiggle, but I don't think it addresses
the issue of composeability. squiggle purports to address this, but it
looks like quite early days for it.

Basically I was trying to stop myself from trying to re-invent this
wheel by myself for Go.

I think when you go for Go (pun intended), then you're bound to re-invent wheels given the lack of adoption of Go so far...

Is there any Java interoperability capability in Go? 

[Ben Hood]

On Mon, Sep 22, 2014 at 12:54 PM, Lukas Eder <lukas...@gmail.com> wrote:
> I know. Well, the query languages essentially work the same way. I just
> guess that SQL is a lot more work than CQL, though.

Very true - CQL has about 3% of the functionality that SQL has.

> I think when you go for Go (pun intended), then you're bound to re-invent
> wheels given the lack of adoption of Go so far...

And indeed I have - I've just started to spike out a solution to see
if it can hold water: https://github.com/relops/sqlc

But I haven't bashed into a shape where I think it's useable for real
world stuff just yet.

You can see where it draws it's inspiration from :-)

> Is there any Java interoperability capability in Go?

It has been done, but I don't think it's hip enough to go mainstream
just yet: https://github.com/abneptis/GoJVM

[Lukas Eder]

2014-09-25 15:45 GMT+02:00 Ben Hood <0x6e...@gmail.com>:

On Mon, Sep 22, 2014 at 12:54 PM, Lukas Eder <lukas...@gmail.com> wrote:
> I know. Well, the query languages essentially work the same way. I just
> guess that SQL is a lot more work than CQL, though.

Very true - CQL has about 3% of the functionality that SQL has.

> I think when you go for Go (pun intended), then you're bound to re-invent
> wheels given the lack of adoption of Go so far...

And indeed I have - I've just started to spike out a solution to see
if it can hold water: https://github.com/relops/sqlc

But I haven't bashed into a shape where I think it's useable for real
world stuff just yet.

You can see where it draws it's inspiration from :-)

Yep :-) Well, I'll certainly be looking out for future developments!

 

> Is there any Java interoperability capability in Go?

It has been done, but I don't think it's hip enough to go mainstream
just yet: https://github.com/abneptis/GoJVM

what?? 

======

...

('extreme XML' 

comes to mind).

...

why-in-gods-name 

================ 

... I don't exactly envy you Go guys. I guess for now, I'll be sticking with Java ;-)

[Ben Hood]

On Thu, Sep 25, 2014 at 5:06 PM, Lukas Eder <lukas...@gmail.com> wrote:
> ... I don't exactly envy you Go guys. I guess for now, I'll be sticking with
> Java ;-)

That's the first time I've been called a Go guy - statistically
speaking I still write more lines of Java per week than I currently do
with Go, hence I must also be a Java guy :-)

[Stéphane Cl]

Have we, java guys, become spoiled by our fancy tools and database frameworks?

I am personnaly interested by many languages and often get frustrated by the lack of appropriate SQL toolkits or weak IDE support... When I first had a look at GO when it came out, my first reaction was exactly that "How will I query my database?" The inevitable question that comes next is "Will I be productive enough"? It seems that once you have given up on manual string concatenation to write your data access layer, there is no way back.

Sorry for offtopic

[Lukas Eder]

OK, Ben. By that measure, I guess I could also be called an Xtend / Scala guy, given the fact that I wrote ~ 10 lines of code based on which I wrote opinionated blog posts as if I were a native Scala speaker ;-)

Stéphane: That is very nice to know. No way back :-) I'll continue ensuring that this is a (hopefully) good thing

--

[Ben Hood]

The depth of choice of libraries and tooling on the JVM is one
compelling reason to choose Java for writing an app.

I always try to use the right tool for the job, and in doing so, I'm
impartial about the programming language.

One of the apps I've written in the last year uses both Go and Java
for different purposes, but they form one single application.

DB wise, Go has a long long way to go to catch up to Java.

The first major difference is the availability of platform native
drivers for all sorts of database products. In Java, you don't need to
search around for some OS native (read non-portable) driver that you
link to. For better or worse, you'll generally find that database
vendors provide a JDBC implementation of their own wire protocol.

Go has something similar to JDBC called database/sql, but you'll only
find a handful of implementations for this.

The second major difference IMHO is JOOQ. JOOQ for me is a reason to
stick to Java, if you have an application that uses an SQL database in
a non-trivial way.

In Go, there are a bunch of ORMs and non-ORM thingy's, which are fine
if you want to just do a bit of CRUD. Similarly, if you just want CRUD
in Java, then arguably you don't need JOOQ - there are even more ORM
and non-ORM options for Java.

What I am looking for in a database dongle is:

* A way to back propagate DDL evolution to the code base that is
accessing the DB whilst you are authoring the code.
* A mechanism to leverage SQL's ability to sort, filter, aggregate and
transform data so that you can write re-usable SQL query building
blocks and tightly factor application APIs that access the DB.

JOOQ offers the code generator in conjunction with the type safe
fluent API to provide a solution for my first requirement.

The second requirement is solved by the design of the fluent API such
that queries can be composed and nested and that although you're
hacking away in Java, you are actually thinking in SQL(*).

So why would I bother with sqlc?

Well if Lukas had never taken the time to come up with JOOQ, one might
argue that Java looses a compelling reason to be used. Chicken and
egg. I don't fully agree with the statement that in Go, lots of wheels
still need to be re-invented. I think that many already have, and have
been so with a high level of quality. But the JOOQ wheel hadn't been
re-invented for Go as yet.

In Go, you have a simple type checked language where code generation
replaces generics and OO-stuff. So it seems conceptually it leans
towards two vital ingredients of the JOOQ paradigm: code generation
and type safe API access.



(*) I'm implicitly assuming that because one uses JOOQ, one buys into
the SQL concept. If you don't like SQL, but are obliged to store your
data in a SQL database, maybe you won't feel at home with JOOQ.

[Lukas Eder]

Hi Ben,

Thanks again for your nice words!

Well, I'm going to do everything possible to give you many more reasons in the future to stay with Java :-)

Best,

Lukas