It will probably hurt right now, and I think we both have more important things to do though.

@edvin I think as soon as Gradle 3.5 is out officially, I think it might be good to start using it for a startup project or two just to get familiar. It helps to be ahead of the curve. It prevents urgent need for learning it later.

@thomasnield Good plan. I'll do the same.

I've been working on this today at work. Ill have some stuff to give back on Monday.

Exciting! I've been missing working on this as well, I have a project I want to use it for but things have been crazy lately.

@edvin no worries, me too

I guess you have a thing or two to do at work these days :))

@edvin haha on my first and second day, I've had a lot of people approach me and have high expectations. No pressure. I may push to start a project that would allow me to showcase TornadoFX and Kotlin for rewriting one of the aircraft turnaround metric tools written in MS Access. I've gotten a lot of people asking if I could help with that...

gods rewriting that in anything but ms ACCESS is an improvement

@thomasnield Wow, that sounds like a very nice use case. And if you can rid the world of an MS Access "app" in the process, that's almost like humanitarian aid. Go for it!

not almost, it is humanitarian aid

To quote Mike Judge's Silicon Valley, "to make the world a better place..." by replatforming legacy Microsoft Access applications.

Haha 😆

I'm curious, when you do a Sequence operator that abandons the iteration early, does disposal of JDBC ResultSet happen appropriately?

@thomasnield No, and that would be dangerous. I think I wrote a comment about that in the code. If you need a sequence and abandon it early, you must call

close()

explicitly on the Query, or do

query.use{}

. (I just added that)

Didn't find a comment though, maybe it was in an earlier iteration 🙂

@thomasnield Hmm.. maybe I was too quick.. Should we close the resultSet or the connection in close()?

Perhaps both at times? What if I use operators that only take the first few elements?

If we close the connection, we close the ResultSet, so maybe that's fine. If you wrap in a

query.use { }

block, you can just take a few elements an you'll be fine. Without the use block you'd have to consume everything, or we need to find a hook to close the resultSet.

@mesquka has left the channel

@Petros Paraskevopoulos has left the channel

Hey @edvin, I kind of started creating a fluent JDBC API to work with Sequences that fits my needs. Do you think this should be added to KDBC at some point? My

rxkotlin-jdbc

library can simply add

toObservable()

and

toFlowable()

extensions on top of it.

Hey Thomas! Absolutely, no need to reinvent the wheel if they have a common base. I'd really like to get back into KDBC, because I see myself using it down the line.

I have my idea about how to perform queries, I don't know if that fits your vision though. I don't think the examples in the readme are completely up to date, I will take a look tonight!

@edvin no rush, I'm still maturing things on my end too but I think it's starting to solidify.

I've been using this in production at work for some time.

But I think we can still try to make KDBC the SQLAlchemy of Kotlin, and support multiple idioms and approaches to JDBC querying.

Yeah, that's a good idea. Different approaches from just strings to type safe queries should be supported 🙂