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...(there are some small formatting changes in tests but they are mostly exactly as-is from V1)
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).
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.
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.
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.
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 😐
that's awesome! looking forward to this!
(just committed changes that get me to just 5 failures -- all parameterizer
stuff, which I'm not sure that I want to implement)
great! will start to experiment with it!
@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 🙂
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!).
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).
(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)
thanks sean!
Related: https://github.com/seancorfield/honeysql/issues/275
You are awesome @seancorfield I will start using soon and provide any feedback
@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.