I hit this issue today with clerk + honey.sql: https://github.com/nextjournal/clerk/issues/646 tl;dr: apparently clerk adds some location metadata (probably via rewrite-clj) which makes honey.sql throw up. this is probably not honey.sql's fault, but it did make me wonder: what does honeysql try to do with metadata at all?
FWIW the clerk issue is going to be fixed with this PR: https://github.com/nextjournal/clerk/pull/647
The stacktrace in the issue is malformed.
That looks like non-standard location metadata 😞 HoneySQL already ignores what it knows to be standard location metadata. See the CHANGELOG for the various releases that deal with metadata but essentially it's to support generation of certain types of SQL hint metadata (e.g., index usage etc).
You can specify :ignored-metadata as an option, to ignore more of the metadata, but feel free to create a GH issue against HoneySQL to ignore more things by default.
IMO, as Michiel states in the last comment, it's better to handle it at the Clerk level.
And if it must have custom metadata, why not just put it all under some ::clerk/... namespace? Of course, it might still need some flag set in HoneySQL, but at least it's not a generic :row.
HoneySQL shouldn't crash tho'... It should either a) silently ignore metadata that isn't an appropriate data type or b) coerce it to an appropriate type first.
yeah my preference would be to fix this in clerk, evaluation shouldn't be different just because clerk evaluates something
my question was more in the line of: I hadn't even considered that honey.sql does something with metadata, why is that?
As I said "See the CHANGELOG for the various releases that deal with metadata but essentially it's to support generation of certain types of SQL hint metadata (e.g., index usage etc)." 🙂
ehm ok, yes, you're right, sorry :)
I probably should have used qualified keywords in HoneySQL from the get-go but I wasn't expecting anything else to be adding metadata to the DSL 😞