Btw has anyone benchmarked the performance changes in 21.2?

@ericdallo I've helped @chandru89new by making sqlite compile in a native-image using your "fix" library. https://github.com/borkdude/clj-sqlite-graalvm-native I had to change a couple of clojure-lsp specific config things. But after compiling I still get:

$ ./tt foo
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open_utf8([BI)V [symbol: Java_org_sqlite_core_NativeDB__1open_1utf8 or Java_org_sqlite_core_NativeDB__1open_1utf8___3BI]
	at com.oracle.svm.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:153)
	at com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:57)
	at org.sqlite.core.NativeDB._open_utf8(NativeDB.java)
	at org.sqlite.core.NativeDB._open(NativeDB.java:78)
	at org.sqlite.core.DB.open(DB.java:195)
	at org.sqlite.SQLiteConnection.open(SQLiteConnection.jav
...

Perhaps you can take a look at this.

You can run this project by running ./compile

Sure, Probably something I forgot to migrate from clojure-lsp to the lib

I can try that tomorrow

Perhaps it's just missing the dynamic lib inside the generated image

@ericdallo @chandru89new found the issue, PR coming

the issue is that you should not do any queries on the top-level in a namespace, since those run at build time and this causes strange problems.

Good catch! Also, I remebered I created this sample project using that fix lib: https://github.com/ericdallo/sqlite-graalvm-sample

This PR fixed it: https://github.com/chandru89new/clj-sqlite-graalvm-native/pull/2/files

I still think it's better to generate some JSON files and put that into resources/META-INF of your fix library @ericdallo, that works equally well and doesn't give these incompatibilities with graalvm versions

true!

I tried to do that one time for clojure-lsp to avoid using that lib but it didn't work 😅 I probably missed something

you can still have that lib, but that lib can just expose those JSON files

instead of those Java classes

yes, sounds way better

perhaps the xerial library will even accept a PR for it

that would be the best IMO

I'll can try that this weekend

So a question. How is it that Eric’s sample (https://github.com/ericdallo/sqlite-graalvm-sample) works without any of those META-INF files?

The registration of the sqlite classes happens in his "fix" lib

Because I didn't know that you can just add the configs via META-INF resources 😅

you can see I manually add the graalvm flags here as well: https://github.com/ericdallo/sqlite-graalvm-sample/blob/master/graalvm/native-unix-compile.sh#L14-L29

so part of the config comes from the fix lib and other is manually added via this script

Ah okay!

@borkdude your PR#2 fixed it and things are working great now! Cant tell you how thankful I am to you, @ericdallo and @karol.wojcik for all the help.

I should perhaps add sqlite to https://github.com/babashka/babashka-sql-pods as well :)

@borkdude it still doesn't work as static though 😕

oh crap yeah, static for pod is definitely nice to have

yeah, FYI: https://github.com/xerial/sqlite-jdbc/issues/584

this one does work with bb already https://github.com/babashka/pod-babashka-go-sqlite3

@ericdallo it seems like forking xerial yourself to make it static might be better, then try it out a while and then PR the changes back?

yes I just have no idea how to change those makefile/gcc args to work 😂

It seems the best would be to change gcc to use musl to be real static

yes, but then that lib doesn't work with non-gcc environments. I'm not sure if what you want is possible at all

this is why using a pure Java library has some benefits here (h2, hsqldb), none of these problems

yes 😕

somebody should do a pure Java implementation of sqlite :)

Yeah, I can't believe we don't have that, android is made in Java and use that all the time haha

they also use the C one

there is only one I think, in C

it makes sense

perhaps clojure-lsp can move to hsqldb or h2?

why is it so attached to sqlite?

last time I talked with @snoe, he wanted to make sure transactions were atomic

btw, the xerial one, we could also port that to use the GraalVM C API, then it would work statically I think

how hard is to do that?

> how hard is to do that? it's probably just a lot of work ;)

@chandru89new do you know babashka?

if not, you should really take a look, it's amazing 😉