@User uploaded a file: Untitled

To help decide about case, here is the same statement with upper case keywords:

@User uploaded a file: Untitled

(I corrected the nested select to use

FROM

instead of inlining it in text. Both are valid though.

Upper case would also let us use keywords

"id" from customer.id

=>

"id" IS customer.id

, but I'm not a fan of of it since IntelliJ by default won't include SELECT as an autocomplete after typing a lowercase s

OK. Let's think about this a little. I need to spend some time with the wife tonight 🙂 Talk to you guys tomorrow! Please post if we need more keywords/functionality before we start to play with it as well!

Good plan, good priorities. 🙂

I cleaned up the

IN

syntax so you can write it like this:

@User uploaded a file: Untitled

The old syntax is also valid, so it depens on query what's the best approach.

Do `and`s have to go inside the

where

block or would

where { "id" eq id } and { "name" eq name }

work?

No, that currently would not work.

Back to the wife 🙂

Sounds good 🙂

Where is a wrapper that takes care of removing unwanted ands etc, so I think at least for now we'll keep it like that. It would be a bit more involved if it were to support both syntaxes.

I take that back, now it supports

and

outside of

where

also.

But remember, an and outside of where would fail if you don't add anything inside the where, because if you don't, the where is never rendered and you end up with

select * FROM table and name = ?

. That's why it's safer to wrap inside the where, at least for dynamic queries.

and

is not an infix function though, so you need to write it on a separate line.

In that case, I don't know if it is a good idea to support the outside version. It could lead to some weird bugs.

If so, we can just move the

and

function from

Expr

(the base class of all expressions) and into

WhereExpr

. Easy to refactor if we want to.

If we want to go completely type safe we could support some kind of Table class with fields representing table columns, but I don't know if it's worth it. It would either mean writing boiler plate or using code generators.

Nah, let's not bother. It expands the scope of this thing too much, and it requires more work to use it. I kind of like that you're still dealing with SQL, so let's keep it that way at least for now.

It would probably look something like this:

@User uploaded a file: Untitled

getString

here is

ResultSet.getString(columnName)

with a twist.

The nice thing is that you don't need to deal with aliases for columns, that could be handled automatically.

Nice

I agree, those would be cool features, but way outside the scope of this project.

Next thing you know we're creating annotation processors that connects to your database and creates classes etc..

Now THERE'S an idea 🙂