sql

All things SQL and JDBC...
adam 2020-06-20T20:50:47.297300Z

Is it possible to set :table-fn option globally in next.jdbc? Or I have to wrap all the Friendly SQL Functions for that?

adam 2020-06-20T20:51:50.297800Z

(trying to use update! on a table called user)

seancorfield 2020-06-20T21:24:43.298700Z

What I do at work is to have a def at the top of my SQL namespace that has the default options I want in any/all next.jdbc calls and just pass that as the last argument in each call.

seancorfield 2020-06-20T21:25:17.299400Z

Because next.jdbc traffics in pure JDBC (Java) objects, there's no way to provide "global options" @somedude314

seancorfield 2020-06-20T21:28:43.301Z

But I am working on a middleware/wrapper approach that would allow you to create something "connectable" that could carry additional options. It's tricky because it has to be done in a way that causes no overhead for folks not using it, and that it composes in reasonable ways.

adam 2020-06-20T21:51:44.302200Z

Gotcha, I think I am just gonna wrap it for now. It's an opportunity to avoid passing connectable for the already non-pure function

seancorfield 2020-06-20T21:54:43.302900Z

Ah, you're already relying on the connectable as global state rather than passing it through the call chain?

seancorfield 2020-06-20T21:56:10.303700Z

(I would advise against that since it makes code harder to test and also ties you into a single datasource)

adam 2020-06-20T22:18:11.306500Z

I was injecting it into the Ring's request object via a middleware then my handler was passing it to the hugsql/next.jdbc functions. I thought it would make my code simpler if I make the data source and next.jdbc options for insert!, update! optional

adam 2020-06-20T22:25:28.306800Z

But I can see how that will make my handlers harder to test, won't do it. Thanks for the advice 🙂

seancorfield 2020-06-20T22:58:41.307300Z

Passing it through the Ring request is fine because it's an argument everywhere.

seancorfield 2020-06-20T22:59:01.307800Z

I thought you meant you had it as a global in the namespace where you were wrapping the next.jdbc calls.

adam 2020-06-20T23:24:20.308800Z

Yep. Sorry for the confusion. I was doing the middleware approach then contemplated dropping it above. I will stick with it.