Hi… What is the support for databases in kotlin na...

# kotlin-native

[jcechace]

Hi… What is the support for databases in kotlin native? E.g. is it possible to use for example Postgres? So far it looks like either there really isn’t any db support (except for maybe sqlite and some mobile databases such as Ream / Firebase) or my Google-fu is weak today.

[ephemient]

#squarelibraries https://cashapp.github.io/sqldelight/ supports Postgres on JVM and SQLite on all platforms including Kotlin/Native

[Landry Norris]

I know that iOS has a few options, mainly SQLDelight. I believe SQLDelight supports all native platforms except Linux

[kpgalligan]

Sqldelight supports linux. https://github.com/cashapp/sqldelight/blob/master/drivers/native-driver/build.gradle#L24

[Landry Norris]

Interesting. The readme just mentions iOS, macos, and windows for native.

[kpgalligan]

Guess the readme is out of date then. I haven’t used it on linux but I distinctly remember adding support for linux on the sqliter driver and this PR: https://github.com/cashapp/sqldelight/pull/2456

[Landry Norris]

Good to know it's an option then.

[jcechace]

Yea well… that pretty much confirms the fact that for native SQLLite is one of the few options... So not any real database support for Kotlin/native it seems…I was just curious since with the release of Ktor 2, it could have been a good opportunity for microservices/serverless solutions where cold start is important

[kpgalligan]

I’d say add a ticket to sqldelight. I don’t think anybody’s really been asking for this stuff, so there’s been no focus on it. The jvm has postgres and mysql support, so sqldelight itself can handle the sql features unique to each. I have no idea what the driver world is like for those on, say, linux though.

[ephemient]

the difficulty is there's no JDBC-like standard database connector on native - every one has to be integrated individually with different code and libraries

[ephemient]

but I'm sure you could work with SQLDelight to add support for Postgres on native. it wouldn't require any plugin/UAST work, just the backend

[jcechace]

@kpgalligan SQL Delight is not the issue here… that’s going one abstraction too high. I was essentially asking about database drivers 🙂 . E.g. equivalent of JDBC drivers for JVM

[ephemient]

regardless of Kotlin, that's not something the native world has

[jcechace]

@ephemient exactly, the missing driver is the issue here 🙂 . Anyway thanks for confirming

[jcechace]

@ephemient I am not sure how it is with standardization of such things, however drivers for sure do exist in other native languages

[kpgalligan]

OK. Well, I don’t know much on native outside of the sqlite space. Creating cinterop bindings to native drivers would be pretty straightforward, but there’s no standard layer like jdbc (as mentioned). So, I can see how one might make a native driver to postgres, but not sure how much one would need to add to it vs just wrap the native library (with cinterop).

[ephemient]

a Postgres driver would get you pretty far, there's quite a few databases with wire-compatible protocols

[jcechace]

Yes, that is certainly a possibility. The api would feel alien in kotlin I think. Unfortunately writing a database driver is not something I would feel confident doing.. although it certainly might be a good learning experience

[Landry Norris]

Postgres integration sounds like a really cool thing to tell myself I'll work on as a side project, but never get around to.

[kpgalligan]

I wrote the sqlite one. The design was kind of “lower level” to be used by another driver (for sqldelight) and not super user friendly to call directly. Just wrapping kotlin around the native calls, again, is not too bad, but what gets layered on top of that is where somebody maybe needs to step in and make some decisions. There’s a whole bunch of what you’d call “prior art” to take hints from, but somebody would really need to make this their “fun project”.

[napperley]

On the native side there is ODBC ( https://en.wikipedia.org/wiki/Open_Database_Connectivity ), which predates JDBC and acted as a heavy influence on JDBC. Think of JDBC as the JVM version of ODBC.

[ephemient]

I have the impression that was only for Windows and proprietary databases, https://docs.microsoft.com/en-us/cpp/data/odbc/odbc-driver-list

[napperley]

Most of the major DB systems have their own client C lib. Below are some examples:
• Postgres - libpq ( https://www.postgresql.org/docs/current/libpq.html )
• MySQL - libmysqlclient ( https://dev.mysql.com/doc/c-api/5.7/en/c-api-introduction.html )
• SQLite - sqlite3 ( https://www.sqlite.org/cintro.html )
• Couchbase - libcouchbase3 ( https://docs.couchbase.com/c-sdk/current/hello-world/start-using-sdk.html#documentation-and-examples )
• MongoDB - libmongoc ( https://docs.couchbase.com/c-sdk/current/hello-world/start-using-sdk.html#documentation-and-examples )
• Cassandra - Datastax C ( https://github.com/datastax/cpp-driver )
• Redis - hiredis ( https://docs.redis.com/latest/rs/references/client_references/client_c/ )

[ephemient]

but it seems https://odbc.postgresql.org/ did exist… never touched it before

[napperley]

ODBC isn't specific to Windows and can be used with some open source DB systems: https://www.easysoft.com/developer/interfaces/odbc/linux.html#odbc_apps_c

[ephemient]

so right, on Linux my experience has been that you link directly to the client library for the database, e.g. libpq, libmysqlclient, etc.

[napperley]

Both libpq, and libmysqlclient are examples of DB client C libraries which aren't tied to ODBC.

[ephemient]

I hadn't heard of ODBC on Linux, nor ODBC for the common free/open source databases. so that part was surprising to me

[napperley]

Some DB systems like InfluxDB provide Web Service APIs (interaction usually occurs via HTTP), which although not ideal are another way to interact with the DB, and is programming language agnostic. Some Kotlin Native client HTTP libraries already exist for interacting with Web Services like Ktor Client ( https://ktor.io/docs/http-client-engines.html ) for example.

[napperley]

Having a universal DB library to rule them all (and in the darkness bind them) for Kotlin Native sounds good (idealistic) until reality hits home. Every DB system has its differences/quirks which are large enough to cause chaos, and make providing a universal API not feasible, especially with No SQL DB systems which are all over the place (lack of proper standards - https://xkcd.com/927/ 😆 ).

[James Black]

If you are looking at server less or micro services you could also go with a nosql solution, such as Kodein-db. I tend to start with https://github.com/AAkira/Kotlin-Multiplatform-Libraries to see what libraries are available and what they support. Kodein-DB is found at https://github.com/Kodein-Framework/Kodein-DB

[jcechace]

Yes, Codein DB / Firebase / Or other cloud solutions provided by Azure/AWS are certainly a feasible solution… or anything with http API… I’m was really interested just about the “standard” big players in RDBs world 🙂 . The thought behind this curiosity was if — in time — Kotlin/Native stack could be an alternative to Graal for new projects.

[kpgalligan]

Well, I mean, wrapping native db drivers is more of an incentive thing than a big problem. It’s certainly doable. I’d think there’d be more design work involved than simply putting cinterop in front of the native drivers, though. That and testing/support is where the work lies.