

Show HN: fluent SQL – a minimalistic SQL builder for Java - ivanceras
https://github.com/ivanceras/fluent-sql/
A minimalistic Fluent SQL API for Java built with one compilation unit aimed to resemble the code to your original SQL code
======
cpfohl
Very slick. My only suggestion is to allow a bit more terseness by adding
static versions of all the calls that can happen at the beginning of the
Query. The static versions would just create a new SQL object and pass the
call on to the SQL object's call.

Instead of:

    
    
        new SQL().SELECT_ALL()
    

You could have Query.SELECT_ALL()

Ideally Java would be cool with having Static and non-Static methods with
identical signatures and names, but alas, looks like a static class Query or
whatever would be the way to do this.

~~~
lukaseder
That helps, specifically with static imports, e.g.

import static com.example.Query.*;

------
jhh
This looks very similar to jOOQ in my first impression.
[http://www.jooq.org/](http://www.jooq.org/)

I wonder if the author was aware of the existence of jOOQ?

~~~
ivanceras
Hi, i wrote the code 3 days ago. I wasn't aware of jooq, it looks cool though.

------
zeroDivisible
This is opinion only, so please don't take this as me being negative: I really
like the idea, but there's one thing which need to happen for this to be
upstream.

Most decent IDE's (Idea and few others) are clever enough to understand the
SQL between quotation marks and if connected to database will give you instant
errors if something is incorrect - misspelled names, missing commas, etc.
Sometimes this can be a big time saver.

------
grandpoobah
I wrote something like this for C# just yesterday as I couldn't find an sql
builder with a real fluent interface. I found one which pretended to be fluent
by returning itself after each method call, but that completely misses the
point, because you want each call to create a mutation but leave the original
in tact. That allows me to build a query using all of the WHEREs and then
branch it off into two separate queries.. one for COUNT and one to select the
actual data.

Just wondering.. did you create this to be used in the read layer of a DDD/CQS
based system?

Edit: actually looking at the source it appears this one is similar to the one
i saw in C# where each call just returns the same builder rather than a new
version

~~~
lukaseder
What was the tool you found for C#?

------
ww520
Looks cool. I love DSL style API for chaining calls. Make it so simple.

------
steve_barham
I don't like this. I'm strongly of the opinion that SQL is a beautiful
language, able to express in terse yet readable statements operations which
would take many pages of Java to execute. Why try and wrap it up, and pretend
that you are writing Java, when you're still writing SQL?

Please don't take this as a dig at you or your code - everyone has an itch to
scratch, and I'm quite sure writing this was fun.

~~~
jhh
One advantage is that the compiler checks your queries. In case of the jOOQ
library, it also makes your queries typesafe and abstracts away some specifics
of SQL dialects.

Having typesafety transcend from the database to your "main" language is of
advantage so long as you are using a statically typed language anyway.

All this is possible while maintaining much of the expressive power of SQL.

~~~
steve_barham
I'm with you on the type checking (although this particular library doesn't
seem to offer much in that space). That said, I'd argue that modern tooling
(e.g. IDEA, and by association the static analysis toolchain in Teamcity) are
capable of identifying and validating embedded SQL, particularly when provided
with database metadata.

Essentially, I'm deeply uneasy about embedding translators from one language
into another. As an example, not many people like using BigDecimal to describe
arithmetic operations, despite it having a fluent syntax and improved type
safety (e.g. around implicit conversions) compared to just writing an
expression.

------
andrewcooke
is anyone wants something similar for c, i am looking for beta users (users
that are happy with a beta release, not users less impressive than alpha
users...) of c-orm, which includes (a very minimal version of) this -
[https://bitbucket.org/isti/c-orm/wiki/SQL#markdown-header-
co...](https://bitbucket.org/isti/c-orm/wiki/SQL#markdown-header-conditional-
statements)

------
mimog
Nice, but anyone needing something like this should probably consider looking
at jooq.

------
jkrasnay
Looks cool! I wrote a similar library that's been working out well in my
projects:

[https://github.com/jkrasnay/sqlbuilder](https://github.com/jkrasnay/sqlbuilder)

------
time4tea
Hmm looks a bit like Squiggle SQL, [http://code.google.com/p/squiggle-
sql/](http://code.google.com/p/squiggle-sql/) but less

~~~
ivanceras
I've seen this, but it was a poor choice of words. One thing that I also want
to add is the ALL CAPS on the SQL keywords, the code adds readability.

~~~
lukaseder
ALL CAPS has been discussed on the
[jOOQ]([http://www.jooq.org](http://www.jooq.org)) User Group as well:
[https://groups.google.com/d/msg/jooq-
user/h9qDY83H5gg/WI2XSj...](https://groups.google.com/d/msg/jooq-
user/h9qDY83H5gg/WI2XSjnidlMJ)

I guess it's a matter of taste, but it will certainly resolve ambiguities
around Java's reserved words "case", "else", and "for".

A future version of jOOQ will ship with an API generator that can generate one
or the other version of the DSL. Given that jOOQ is based on a somewhat formal
BNF, such an evolution won't be too hard to implement.

------
icedchai
Looks cool, but personally I'd rather just use regular SQL.

~~~
siddboots
The advantage here is language integration. You can write a query, wrap it in
an object, add clauses to it dynamically, combine it with another query using
some clever logic, and so on.

~~~
ygra
That's probably the only place where I would use it, when I have to construct
a query on the fly based on various conditions. For a plain static query I
think the regular SQL is much easier to read and understand (let alone paste
into a query window to test its output).

~~~
siddboots
Building queries dynamically is the intended use case. This wasn't designed as
a replacement for plain SQL.

