Clojurians Log v2

We have a project at work that uses hugsql with clojure.java.jdbc. To deploy in production we do AOT but last night we got a CompilerException:

CompilerException: Syntax error compiling at (hugsql/adapter/clojure_java_jdbc.clj:11:7).
...
RuntimeException: No such var: jdbc/db-do-prepared-return-keys
    at clojure.lang.Util.runtimeException(Util.java:221)
    at clojure.lang.Compiler.resolveIn(Compiler.java:7388)
    at clojure.lang.Compiler.resolve(Compiler.java:7358)
    at clojure.lang.Compiler.analyzeSymbol(Compiler.java:7319)
    at clojure.lang.Compiler.analyze(Compiler.java:6768)

Has anyone seem that before or has any lead of how to debug this? A related question: should be a java class for each aot compiled clojure namespace? I looked at the uberjar but found the structure way different than I expected but that may be just my ignorance of what should be in there.

The code is is production for a long time and we never saw that error before. What changed a couple of months ago is the addition of AOT.

aot compilation has a habit of shaking and weird unexpected things in your code base

two places to start on your error would be making sure you don't have any stale class files laying around (class files generate from previous aots), and checking your dependency tree to see if you are somehow pulling in a different version of clojure.java.jdbc than expected

did you get that error compiling or when running?

@hiredman thanks for taking the time to respond. It happened when running. The uberjar is built on a ci server so no stale classes should be possible. I will check the dependency tree.

the next thing to do will be to look at your dependencies to make sure none of them are aot compiled with an older version of jdbc

. org.clojure/java.jdbc 0.7.6 which should be good.

Hum, should I look inside jars for that?

yes

that stacktrace is also very odd to happen at runtime after aot compiling

(since it is coming from the compiler, which shouldn't happen if everything is aot compiled)

when you aot what you should get out is to some degree a function of what your build tool is, and how it manages its aot feature

Ok, thanks for the direction. Will report back what I find. I found some .clj files on the uberjar, not sure if those are expected. I'm using depstar to create the uberjar.

Especially since that function -- db-do-prepared-return-keys -- has been in c.j.j for a long time and hasn't been touched since that 0.7.6 release.

the way the clojure compiler handles it is all the code loaded while aot compiling generates classes

(well generates classes that are saved to disk"

so for example, if you are preloading any code before triggering aot compilation, it won't be aot compiled unless you reload it, which can be a problem

@mynomoto Yes, if there are paths in the code that do not statically reference certain namespaces, those will not be AOT compiled for just :main-class with depstar. You could try :compile-ns :all.

What version of HugSQL are you using BTW?

com.layerware/hugsql 0.4.9 I checked the changelogs over there but I didn't find anything suspicious.

That should be recent enough to be fine. I would check your dependencies with clojure -Stree and see if older versions are lurking elsewhere in your transitive deps.

You might try hugsql 0.5.1, since there was a fix related to requiring and setting the adapter that might help with AOT issues.

I just did that as suggested by @hiredman but there is only one reference both to clojure.java.jdbc and hugsql.

Ok, I will try that, thank you!

https://github.com/layerware/hugsql/issues/46#issuecomment-255571290 hah

Oh, thank you! I missed that when searching on github.

Thank you @hiredman, @seancorfield and @curtis.summers. Looks that upgrading to the latest version of hugsql should fix it.

Ah, yes. Somehow I'd missed the changes since 0.4.7 via the link I'd turned up. Here's the issue you're talking about @curtis.summers https://github.com/layerware/hugsql/issues/105 ?

Looks like #46 introduced a regression that got fixed in 0.5.1 in #105

I think this commit that was released on 0.5.0 was the one that fixed the issue but caused the bug that was fixed in 0.5.1 https://github.com/layerware/hugsql/commit/8a908f7a5de37d232183a3bebc2f9e4ab26812a3