Learning about Exposed a bit more from this <kotli...

# squarelibraries

[Colton Idle]

Learning about Exposed a bit more from this

kotlinConf talk▾

. I'm new to server dev and have been using sqldelight, but I'm still sorta unsure if sqldelight and exposed can work together or not? seems like exposed can help with db connections, and then could i use sqldelight for my actual table setup and queries, etc? Or am I basically misunderstanding this and you would instead only use exposed or only sqldelight? thanks!

[jw]

You cannot mix the two. Exposed doesn't help with connections, it will use something underlying that you can also use with SQL delight

[Adam Brown]

I used Exposed for past projects, I think like many semi-magical ORM like solutions, its really great for smaller projects, but I always end up running into problems as the project gets more complex. SqlDelight is a really nice middle ground that still gives you all of the power you'd expect.

[jw]

Connections are generally handled by Hikari

[jw]

Or they were a decade ago. I don't know what's modern, really

[Colton Idle]

Yeah. thats honestly maybe whats driving me a little crazy here. being a noob and doing this hikari setup was such a pain. and im just like... there must be some better way. lol

[hfhbd]

On JVM, sqldelight and exposed uses JDBC. What tool (eg hikari) you use to provide a JDBC connection is not important to sqldelight/exposed. And you can’t mix them, sqldelight uses a compile based approach, while exposed uses a dsl runtime approach. Both have pro and cons.

[Colton Idle]

is hikari still kinda the standard. or is there something newer at this point thats better suited for kotlin?

[hfhbd]

JDBC is part of the Java SE, so you can't really optimize a JDBC datasource implementation for Kotlin because you need to implement the Java APIs. And I don't know if you need some optimizations for Kotlin at all.
Hikari is de facto the standard, there are others too, but it is widely used and does offer great performance according to tests.

Personally, I never used hikari AFAIK, at work we use Java EE using WARs, so an application developer orders a datasource which will be provided as a Java EE resource. Which framework/tool is used under the hood is an implementation details that can change. For private projects, I often use the driver directly because I am lazy, I don't need such performance.

[Colton Idle]

gotcha. yeah. im trying to just connect ktor to sqldelight. and i can't. lol. Id like to not have to use hikari if i can just use jdbc directly.

[Colton Idle]

hikari seems to work easily like this

val ds = HikariDataSource()
        ds.driverClassName = "org.postgresql.Driver"
        ds.jdbcUrl = "jdbc:<postgresql://viaduct.proxy.rlwy.net:1234/railway>"
        ds.username = "postgres"
        ds.password = "password"

        var driver: SqlDriver? = null

        driver = ds.asJdbcDriver()

[Colton Idle]

because of these docs too i thought the way to do it was hikari since thats what it mentions

https://cashapp.github.io/sqldelight/2.0.0/jvm_postgresql/#typesafe-sql

[Brandon Chapman]

sqldelight is working out well enough. I looked at exposed and decided against it. The only issue I'm currently facing is having to near duplicate the generated data classes for requests that don't utilize all generated properties. It's annoying, but manageable

[Brandon Chapman]

@Colton Idle I found the initial setup (and docs) to be rather lacking. It seems that everyone goes through this initial hickup phase then doesn't process it further. Just insanity. Feel free to reach out if you just need to see it working and then can go from there.

[Colton Idle]

yeah. i mean. if i can get this working without hikari that'd be nice. i kinda dont know what im doing here since im not a backend dev. so its my first time trying this sort of stuff. kinda foreign to me because in android theres no connection that has to be made.

[jw]

There is

[Brandon Chapman]

I used hikari and would suggest you stick to it. I understand the desire to reduce tooling to it's bare bone necessitites and/or work with what you know and just introduce a small set of new tooling at a time until you gain competency. My suggestion is to start up a sample project and just focus on having success with hikari outside of your sqldelight project. That's my typical approach. Prove success with the most basic application of a new tooling, then integrate.

[Colton Idle]

going to give the docs of this site a whirl. https://jdbc.postgresql.org/ sounds promising. hopefully can get a data source which plays nicely with sqlDelight!

[Colton Idle]

https://jdbc.postgresql.org/documentation/datasource/#table112datasource-implementations

Looks like there is org.postgresql.ds. PGSimpleDataSource and org.postgresql.ds. PGPoolingDataSource