Clojurians Log v2

What do you mean by execution? Simple Gungnir usecase: Query:

{:select :* :from :user :where [:= :user/email "KEVIN@MAIL.COM"]}

string/lower-case :user/email

{:select :* :from :user :where [:= :user/email "<mailto:kevin@mail.com|kevin@mail.com>"]}

@kevin.van.rooijen I mean that the transformation "doesn't matter" until the value is about to be stored into the DB or has just been retrieved from the DB. You've attached Gungnir to SQL generation but a similar transformation could be done against next.jdbc around the setting of parameters and the reading of SQL values back from the DB.

I'll take a deeper look at Gungnir over the next week or two and discuss my thoughts in more detail after that -- but my gut reaction is that attaching this to the set parameter / read result set functionality in next.jdbc would be "better" because then it would operate on things like update! and insert! from next.jdbc.sql.

I mean that the transformation "doesn't matter" until the value is about to be stored into the DB or has just been retrieved from the DB. I don't think this is correct. Because I'm lower-casing the email in my query, not the resulting values. This is so that I don't have any case matching issues

But maybe this can be solved in next.jdbc as you said

You misunderstand: You need the parameter lowercased before you store it into the parameter, as part of the prepared statement setup, for your query. Which could happen in next.jdbc's set-parameter -- and which would then apply to all of the ways you could run queries, not just those that go through HoneySQL.

And if this was wrapped around next.jdbc, Gungnir could also transform values coming back from the DB if needed -- although that is orthogonal.

To illustrate my point: if you do (jdbc/execute! ds (-&gt; (select :*) (from :user) (where [:= :user/email "<mailto:KEVIN@MAIL.COM|KEVIN@MAIL.COM>"]))) Gungnir would intercept that but if you did (sql/find-by-keys ds :user {:user/email "<mailto:KEVIN@MAIL.COM|KEVIN@MAIL.COM>"}) it wouldn't -- with Gungnir based on HoneySQL; but Gungnir could intercept the second version as well if it was based on next.jdbc. Does that make more sense?

Right, so basically what I'm doing now could be handled with set-params. I'll take a look at that this week then, sounds like a much better solution

Feel free to ping me if you have Qs -- the qualified name is not present by the time set-parameter is called but the metadata, available through the PreparedStatement, may provide enough information.

And although clojure.java.jdbc has a different protocol, the machinery should be the same, so you could have one ns for next.jdbc and a separate ns for c.j.j if you wanted to support both libraries.

I'm already using some features from next.jdbc so it's already required 🙂

Thanks for the tip

I just took another look at it and I don't think there's enough metadata to figure it out: the parameter metadata only has type information and no concept of naming; and the result set metadata is about what comes back not what goes in.

Which means the level you need access to is above the SQL statement / parameters, unfortunately. 😞

Hmm that's unfortunate

Is it possible to patch this to add the extra metadata?

Would be a good excuse for me to dive into next.jdbc

Yes, you could extend the protocol via metadata on a value-by-value basis -- the trick I've been using is to wrap the value in a function (`constantly`) so the protocol implementation can easily retrieve the original value.

That's how the next.jdbc.types type adapters work.

I've just been looking at the Gungnir source code: it looks like it overrides a specific set of operators within HoneySQL to provide the before-read transform of the values associated with certain (qualified) keywords -- is that accurate?

(and it also wraps some of next.jdbc to achieve the same thing directly with insert! and update!?)

Right, with Gungnir you can transform specific qualified-keywords defined in the model https://kwrooijen.github.io/gungnir/model.html It supports three things: :before-save - Done within gungnir, separate from HSQL / NJ :before-read - Patched version of HSQL (linked in the issue of HSQL) :after-read - custom result-set builder with NJ https://github.com/kwrooijen/gungnir/blob/master/src/clj/gungnir/database/builder.clj

You can read me model document for the use cases / how they are implemented by the end-user. It's all based on qualified keywords

Given HoneySQL v2's recursive descent formatting -- which is independent of the actual operators/function calls being used -- it's certainly a lot harder to implement a hook like that. I'll continue to give it some thought.

All right. I'm a bit in between projects right now so Gungnir doesn't have my highest priority at the moment. Worst case I'd have to walk the HSQL datastructure but hopefully we can prevent that

What would you do with an expression like this in Gungnir? (where [:= :user/email [:|| "KEVIN" "@" "<http://MAIL.COM|MAIL.COM>"]])

(it would produce ["... WHERE email = CONCAT(?, ?, ?)" "KEVIN" "@" "<http://MAIL.COM|MAIL.COM>"])

the [;|| "KEVIN" "@" "<http://MAIL.COM|MAIL.COM>"] part would be in the user defined part. So you'd for example have this (end-user defined)

(defmethod gungnir.model/before-read :string/lower-case [_k v]
  (clojure.string/lower-case v))

(In this example it would fail because we're using string/lower-case on a vector, but the user could change that)

@kevin.van.rooijen Ah, good to know. OK, that gives me some ideas then...

Let me know if you need any more info (sorry for the occasional late replies, timezones 😄 )

To be expected when I'm on Pacific time and you're on Dutch(?) time 🙂

Yep