Squiggle and jOOQ

[Lukas Eder]

Hello Squiggle guys,

I have found a reference to your project on Stack Overflow. It looks
like Squiggle is not an active project anymore. Did you have plans to
continue working on it?

Or would any of you be interested to bring in some of your ideas in
jOOQ? I am developing jOOQ for very similar purposes. Unlike Squiggle,
however, jOOQ aims on providing full SQL support, including nested
queries, nested tables, arrays, UDT's, stored procedures, recursive
queries, etc. Feel free to have a look at jOOQ:

http://www.jooq.org

Cheers
Lukas

[Joe Walnes]

Hi Lukas

Squiggle is a project I originally wrote a very long time ago. 1999! I
honestly can't remember the last time I even thought about it, until
now. So, no, I have no plans to continue working on it.

I've had a look at jOOQ. Looks very good. Indeed, they seem to have
very similar goals. But you have momentum :).

So feel free to take any ideas you want, and fold in any code you feel
useful.

One suggestion I have (actually I'm just relaying some advice that Nat
Pryce gave to me many years ago, that has worked out well), is to have
a clear separation between the object model (i.e. AST of the query)
and the high level builder style API. The reason is that this allows
the model to be easily adapted to other types of APIs as trends
change, and offers up more flexibility for users to extend.

cheers
-Joe

[Lukas Eder]

Hi Joe,

Thanks for your feedback!

> Squiggle is a project I originally wrote a very long time ago. 1999! I
> honestly can't remember the last time I even thought about it, until
> now. So, no, I have no plans to continue working on it.

I didn't know that these attempts to find type-safe query solutions
went back to 1999. I guess it's safe to say that you guys were ahead
of your time. Too bad you didn't continue working on it back then...

> So feel free to take any ideas you want, and fold in any code you feel
> useful.

Thanks for that

> One suggestion I have (actually I'm just relaying some advice that Nat
> Pryce gave to me many years ago, that has worked out well), is to have
> a clear separation between the object model (i.e. AST of the query)
> and the high level builder style API. The reason is that this allows
> the model to be easily adapted to other types of APIs as trends
> change, and offers up more flexibility for users to extend.

I already follow that principle with the support of a "classic",
object-oriented API, similar to yours, and a fluent API modelling SQL
as an internal domain specific language in Java (which is probably
what you called the "builder-style API". I agree that this separation
made my life much easier, and probably helped my users to write SQL
much more efficiently, as the builder-style API is more intuitive.

Cheers
Lukas