Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2021-07-12

Channels

#honeysql
<
2021-07-12
>
zackteo13:07:28

Hello, may I know if there is a good way to changed the namespaced keywords (based on the table) to normal keywords in honeysql? Am thinking it is removing the namespace part is better when I pass the resulting sql result to my frontend. I know I can do something like ... 

(zipmap (map (comp keyword name)
               (keys sql-result)) (vals sql-result))
do i just do that?

thumbnail15:07:44

There might be a better way; but aliases don’t get a namespace. So if you {:select [[[:user/id] :my_id]]}; it returns :user/id as :my_id

seancorfield18:07:45

@UUSQHP535 I don't understand the context of this question. What perceived problem are you trying to solve? I've never needed to do anything like this.

zackteo03:07:57

@U04V70XH6 I was thinking of renaming/removing the namespace from the keywords. So that my frontend doesn't need to know in which database table the column of data comes from

seancorfield03:07:31

I'm not sure what that has to do with HoneySQL? You use HoneySQL to generate SQL that you then pass to a JDBC library (by which point namespaced keywords have been processed/removed).

seancorfield03:07:53

The JDBC library might give you back namespace-qualified keywords but that has nothing to do with HoneySQL.

seancorfield03:07:56

You can tell the JDBC library to not qualify column names -- but my recommendation would be to allow that and to have a transformation at the boundary where you pass data back to the frontend: I would argue that in general the over-the-wire data you send from the backend to the frontend should be a specific API (that suits the client) and should not just be an exact copy of the data model used inside your backend.

seancorfield03:07:30

In my handler function, which returns data to the API, I would probably either destructure the data to extract just the fields the API needs (and give them appropriate "API" names) or use a combination of select-keys and clojure.set/rename-keys to produce an appropriately named data structure for the client.

seancorfield03:07:16

This isolates your frontend code from any changes in your data model -- and also allows for your frontend/API to change independently of your data model.

seancorfield03:07:19

The data structures going back and forth between your API and your client are a good candidate for validation with Spec (using :req-un/`:opt-un` keys).

zackteo04:07:53

oops, yeah you are right, this is a next.JDBC. Was getting things mixed up because was concurrently thinking if i should be renaming it with :as in sql

zackteo04:07:50

Thanks for your advice! Let me try to implement what you explained

borkdude18:07:32

does honeysql support this syntax in do-update-set? 

;; do update set (docdata_user_id, docdata_client_id, profile, last_login, _updated, login_count) =
;; (:docdata_user_id, :docdata_client_id, excluded.profile, now()::timestamp, now()::timestamp, users.login_count + 1)

borkdude18:07:43

so set (x,y,z) = (foo,bar,baz)?

borkdude18:07:53

I'm trying to convert a hugsql query

seancorfield18:07:21

@borkdude I don't think you can do a composite set like that, but you can specify a hash map of columns/values that it will set: :do-update-set {:docdata_user_id :docdata_user_id, :docdata_client_id :docdata_client_id, :profile :excluded.profile, :last_login ..., :_updated ..., :login_count [:+ :users.login_count 1]}

borkdude18:07:50

oh that's equally good

seancorfield18:07:09

(I'm not quite sure what the best way to write the cast syntax is [:cast [:now] :timestamp] would probably work)

borkdude18:07:17

I don't care about the SQL it generates, as long as it's the thing that's semantically the same

borkdude18:07:34

yeah, I can always do a :raw for that as well

seancorfield18:07:08

The docs have an example of :do-update-set with a hash map BTW