honeysql

Discussion of https://github.com/seancorfield/honeysql :slightly_smiling_face:
seancorfield 2020-09-24T01:25:28.001900Z

Just as an FYI, I've been sketching out a V2 of honeysql and it passes all but 8 of the V1 format tests:

Ran 75 tests containing 163 assertions.
8 failures, 0 errors.
The failures are because I have not yet implemented inline, array, or the parameterizer machinery. And it's also highlighting that there is a lot of functionality in HoneySQL that doesn't have any tests right now...

seancorfield 2020-09-24T01:26:05.002500Z

(there are some small formatting changes in tests but they are mostly exactly as-is from V1)

seancorfield 2020-09-24T01:29:54.005200Z

I'm embracing the concept of dialects at the core of this. You will be able to set a default dialect for all operations, or specify a dialect on a per-`format` call (for cases where you are actually working with multiple different database engines in a single application... that is partly conceptual right now as I haven't quite figured out the mechanics to make that work in all cases, when you can also register new clauses at will).

seancorfield 2020-09-24T01:31:25.006200Z

The extension mechanism should be a lot simpler to work with: you can register new clauses by specifying a "rank" position for them within the existing clauses and supplying a formatting function.

seancorfield 2020-09-24T01:32:38.007200Z

There are no helper functions yet -- I plan to have those auto-generated from the list of known clauses so that everything will stay in sync, even if you change dialects and/or register new clauses of your own.

seancorfield 2020-09-24T01:35:03.008300Z

There's no multimethods, no custom record types. But there's also no inline, raw, array, etc yet so I still have to figure those out.

seancorfield 2020-09-24T01:38:28.010900Z

It's very ugly, undocumented code right now -- I'm really just exploring how to provide enough code generation machinery from the (existing) DSL to provide all the building blocks needed to construct "any" SQL construct going forward. Some of the current code is complicated simply because I'm trying to preserve backward compatibility with the DSL itself -- so migration will be easier -- but there are definitely some "quirks" in the current data structure used for that 😐

dharrigan 2020-09-24T06:06:00.000400Z

that's awesome! looking forward to this!

seancorfield 2020-09-24T06:17:31.001200Z

(just committed changes that get me to just 5 failures -- all parameterizer stuff, which I'm not sure that I want to implement)

🔥 1
2020-09-24T09:31:43.002200Z

great! will start to experiment with it!

dharrigan 2020-09-24T14:03:28.003400Z

@seancorfield will you be adding a groupid to the library, as is recommended now with the updated clojure tools? Presently, I'm using honeysql/honeysql to avoid the warning 🙂

seancorfield 2020-09-24T15:30:03.007100Z

Yeah, I have to think about that. Right now, it's just on a branch with a new namespace added (`honey.sql` containing the entire formatter). Technically, it has a group ID -- it's just the same as its artifact ID, which means honeysql/honeysql is the correct coordinate. If I release it under a new group ID, you wouldn't be able to have both libs on your classpath right now, because it also includes all the (old) current namespaces and they'd cause a conflict (but of course you could just use seancorfield/honeysql in place of honeysql/honeysql because -- still having all the old code -- means it is a drop-in replacement!).

seancorfield 2020-09-24T15:33:53.008900Z

As I start to document it all and flesh out the Specs (`honey.specs` exists but isn't very useful because I hadn't figured out much of the DSL, since it isn't really documented -- I've been reverse-engineering my understanding of it based on tests and existing behavior).

seancorfield 2020-09-24T15:56:41.010600Z

(I'm on vacation until Tuesday so I expect I'll spend quite a bit of those five days working on HoneySQL v2 -- so now is a good time for everyone to provide feedback in GitHub issues! https://github.com/seancorfield/honeysql/issues has some placeholders already for V2 discussion but feel free to create additional issues if the current ones don't cover some particular pain point for you)

dharrigan 2020-09-24T16:36:15.010800Z

thanks sean!

seancorfield 2020-09-24T17:05:27.011Z

https://github.com/seancorfield/honeysql/issues/274

seancorfield 2020-09-24T17:30:59.011300Z

Related: https://github.com/seancorfield/honeysql/issues/275

2020-09-24T18:50:02.013300Z

You are awesome @seancorfield I will start using soon and provide any feedback

seancorfield 2020-09-24T19:17:32.014400Z

@jmayaalv Still very early days for v2. I'd certainly be happy for folks to try it out via :git/url but there's zero documentation published ATM.

👍 1