Fork me on GitHub

Is there a way to remove the table namespace part of a result when aliasing? Or do I have to turn off table namespaces at the JDBC level completely? For context the table namespaces are handy but we’ve recently started pushing more on to the database. So we get the database to return the keys the client wants (where namespaces matter less because json/js).


I'm having a hard time associating the questions here with HoneySQL. Can you provide a more concrete example of what you're asking? I think you're asking about next.jdbc behavior perhaps and not HoneySQL?


With when you alias you still get :table/alias-column-name. Is there any way to just get :alias-column-name? For a specific result/set query. .ie without turning all result sets into unqualified results. I posted it here cause I thought honesql might have some syntax for that, like :unqualified or something. Pretty uncommon used case. I think it might be easier for me to either pass in unqualified-snake-kebab-opts when calling execute! or just stripe out the qualification in clojure. I’ve somewhat answered my own question. I guess I’m having a bit of a keyword existential crisis. I’ve been enjoying the qualified keywords (previous project didn’t have them as we were using the old jdbc lib), but honeysql makes writing sql so nice that we are now using postgresql to build the exact data the client expects, so suddenly qualified keywords are a hindrance. But I’m not quite ready to drop them completely, so was looking at some halfway house of being able to turn them off in certain cases. 😅


HoneySQL just builds SQL. It doesn't execute it.


You can specify a :builder-fn for an individual call to next.jdbc/execute! If you really need to. But I would recommend explicitly building the client data from result sets at the point of handoff, rather than trying to do that purely at the database level - you're mixing abstraction levels.

👍 1

“you’re mixing abstraction levels.” - You’re right. You’ve put into words what has been bothering me. Maybe we’re pushing too much onto the database, next thing I know I’ll be writing stored procedures. I guess just because honeysql makes it pleasant to do almost everything ins SQL, doesn’t mean you should. Thanks for the advice!