I'd like to have one

value-that-returns-nullable

and another

value-that-returns-non-null

for more convenient usage. What would I call these two?

p.name.valueNotNull

and

p.name.value

.. but the first is too verbose. Any suggestions?

For now I added an

invoke

operator function to column, so you can write

p.name()

to get a non-null version and

p.name.value

to get the nullable version. Bad symmetry, but very nice and short.

Just had a couple of more revelations 🙂 Major restructuring going on!

One small cool thing that came from this.. Let's say you want to select all columns in two tables and join them

@User uploaded a file: Untitled

Columns is an automatic list of all declared columns for a table. Here, I also defined that CustomerTable class inside Customer, but that's entirely optional. More info tonight 🙂

I'm also thinking that there should be no need for plain strings anymore, this type safe way is so much nicer to work with.

I'm also thinking that it's a good idea to create a class for each query. It has many advantages, amongst other things it can support multiple queries, like

all

,

getById

etc. Will post an example soon.

Holy cow, this IS getting magical

Cleaning up error messages. I hate SQL frameworks that give you an error, but you can't easily understand where the problem is.

@User uploaded a file: Untitled

I got lot's of ideas from an SQL guru at work, so I'm trying to incorporate them as best I can 🙂

Going out to eat now, will pick up again later.

Next thing to get right is TypeHandlers: The converter that knows how to apply a java object to a PreparedStatement parameter.

Sorry that this is taking so long, but I'm trying to establish some temporary best practices before I make a screencast.

😄 Takes time to get it right, that's just fine.

I'm very happy with how it works now, and I hope I'll be able to convey the power of this approach :))

I'm going to need some test data for the sceencast as well..

Added support for transactions and datasource. Now you can use a

DataSource

as a

Connection

without even thinking about it 🙂

We might add some more metadata to the Table/Column definitions so they can be used to auto generate DDL.

Now I'm working on UPPER()/LOWER().. That was a bit involved 🙂

You're aiming for core SQL, yes?

Hmm. How would this interact with different drivers?

Yes, this is all SQL-92 compatible, but it would be easy to add specialized instructions for custom databases, for example adding support for Oracle DB

WHENEVER

is just a matter of implementing the Expr class and adding an extension function, so everybody can do it themselves, or submit a PR to add it to core. I think it is OK that we have keywords available that might not work with your SQL dialect. If so, just don't use it 🙂

Quite true. One of the upsides of this templating approach. 🙂

Ah, everything just fits. UPPER/LOWER is working perfectly.

That's a good sign 😄

The rate of addition of these new features also speaks well to the design....

Yes, I remember how much I struggled when I tried to juggle text everywhere. It's a nightmare. This just feels right.