Clojurians Log v2
honeysql
An update on HoneySQL 2.0: nearly all of the README tests pass now -- which means many of the helper functions are in place and being tested now, I fixed some bugs in VALUES formatting, fixed aliasing as strings, I've added :select-distinct in place of the previous :modifiers machinery _so I'd like to hear from folks using :modifiers for something other than just :distinct, I implemented an equivalent of :parameterizer :none (an :inline? option), re: UNION I have now updated that to parenthesize the sub-clauses (until and unless we find cases that breaks in some DBs and then I'll revisit how that logic works, perhaps making it a dialect-specific setting). The remaining failures are: 2 :raw tests with a compound argument (I haven't decided how best to handle this), a composite handler issue, and a problem that I think is due to parameter lifting.
What are contributor's guidelines, especially for new contributors?
The same as pretty much any FOSS project on Github, I guess. Not really sure what you're asking?
I was referring to this probably, I think it can help converting users of project to contributors: https://seld.be/notes/encouraging-contributions-with-the-easy-pick-label
Ah, yeah, right now there are no open issues for HoneySQL that would fall into that category. next.jdbc has a "Good first issue" label but no open issues in that category right now, same with depstar, clj-new, and readme. I've added that label to HoneySQL for future possible issues.
The readme now includes documentation on the new extension mechanisms -- and the existing docs/tests in the README have been rewritten to use that instead of the old multimethod approach. See https://github.com/seancorfield/honeysql/tree/v2#extensibility
The next piece of work planned is to work through all the v1 helper tests and core tests and migrate as many as those as possible/relevant over to v2 so I can get more compliance for the DSL and helpers in place, along with fixing the remaining known issues (from the readme work above).
(oh, I should mention that while nearly all the new keyword options in v2 are :<something>? those question marks are probably going to go away as I really don't like ? on keywords -- only on actual predicate functions -- and I consider many of the current v2 options to be placeholders right now, and several might became multivalued instead of just Boolean anyway)
that's awesome work Sean! I looked through my codebase and all I use is :distinct as a modifier 🙂
I thought about the clj-kondo issue some more. Enforcing this via a linter might have some edge cases. E.g. destructuring someone elses data that does contain keys with questions marks will require renaming those opts instead of just keys destructuring.
I think if you really want to enforce this for your own code, you could simply turn it off around 3rd API-interacting code?