Comments (5)
I think the confusion here is that the clojure.java.jdbc
library now no longer supports var-args for it's options. But HugSQL supports the ability for the underlying library/adapter to support any number of additional arguments. For the purposes of clojure.java.jdbc
, though, your code should include the options in a single map and not call apply:
(let [command-opts {:row-fn tx}
db-fn* (-> queries q :fn)]
(db-fn* db (db/clj->sql params) {} command-opts))
from hugsql.
Ok I can do that but I wonder whether it is a good idea, from a library that abstracts over adapters perspective, to behave like that.
It feels more natural to drop the apply with hugsql and either deprecate or special case for the old version of clojure.java.jdbc
.
I personally saw the signature and went with apply cause I expected hugsql to handle that. Does all this make sense?
from hugsql.
I'm not quite sure I understand from your code, as you have to use a hashmap if you use apply
or not because that's what newer versions of clojure.java.jdbc
expect:
Without apply
w/ a hashmap:
(let [command-opts {:row-fn tx}
db-fn* (-> queries q :fn)]
(db-fn* db (db/clj->sql params) {} command-opts))
With apply
you still need the hashmap, just wrapped in a list/vec:
(let [command-opts [{:row-fn tx}]
db-fn* (-> queries q :fn)]
(apply db-fn* db (db/clj->sql params) {} command-opts))
From a library perspective, you're asking to create a backwards-incompatible version by removing apply
from the adapter. This breaks a contract. The current adapter supports both cases: the older calling convention and the newer one.
The fact that the first argument of command-opts
must be a hashmap for the newer calling convention was not a HugSQL decision: it was a breaking change in the clojure.java.jdbc
library. This is even mentioned in the docs:
Please note that as of clojure.java.jdbc 0.5.8 and HugSQL 0.4.7, the above additional options are now required to be a hashmap instead of keyword arguments as in previous versions. In clojure.java.jdbc 0.5.8 the deprecated usage will emit a warning. In clojure.java.jdbc 0.6.0 the usage is deprecated and not allowed. See the clojure.java.jdbc changelog for details.
(I understand why clojure.java.jdbc
moved away from keyword args because they are, quite frankly, more trouble than they are worth, but I'm not sure it was a great library move to remove the signature altogether.)
from hugsql.
Thanks @csummers for the detailed response.
In the eye of a library user, passing a map instead of a series of keyword value keyword value
is still a breaking change. My apply
with a vector above was trying to comply with the & command-opts
part of the signature and expecting hugsql to deal with passing things to the adapter. Apologies for reiterating but I am just trying to explain my point of view.
From a library perspective, you're asking to create a backwards-incompatible version by removing apply from the adapter.
Agree now that that is not the right approach. I am leaning more towards detecting somehow if that clojure.java.jdbc
function accepts multi-arity or plain map (probably inspecting metadata). Anyways, it seems the direction here is to warn in the README (that I missed thank you!). In my inherited code base probably someone stumbled across the same problem and decided not to pass any options and do everything in a wrapper - tech debt was born 😄
Closing.
from hugsql.
@arichiardi Thanks for understanding. I realize it's not ideal. I think if the original signature for clojure.java.jdbc/query
had not used keyword arguments, then it's likely that command-options
would not have been var args in the first place.
The boundary is tricky since I want HugSQL-defined functions to not differ too much from the underlying library's calling expectations. So, the variable arguments of command-options
does provide some flexibility for the HugSQL-defined functions to match the underlying library's expectations either way: imagine an underlying library that is not using keyword arguments, but still needs multiple positional arguments.
from hugsql.
Related Issues (20)
- Taking array as an input
- Not able to update multiple column values
- Optional null parameters HOT 1
- Way to get generated SQL without executing? HOT 1
- Add support for next.jdbc.sql/insert-multi! HOT 1
- Incorrect Arities Shown in Docs for def-fb-fns HOT 1
- HugSql fails during AOT compilation with depstar HOT 4
- Switch to newer groupId of next.jdbc dependency in hugsql-adapter-next-jdbc HOT 1
- How to use a function from the database? HOT 2
- Migration fails if a comment is present on line with semicolon HOT 2
- Babashka support HOT 2
- No comments in doc on mobile? HOT 1
- Using classpath resource sql functions breaks cider HOT 3
- Hugsql 0.5.3 still requires SQL files on uberjar compilation (with leiningen) HOT 1
- strange key with jsonb HOT 3
- Should hugsql switch to next.jdbc by default ? HOT 2
- Cannot look up by UUID HOT 2
- Bulk update? HOT 1
- Inline parameters
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hugsql.