Not really. How would that work for two users, one on 198 and one on 199

If you never shipped a version to users then you could combine them, yes, but otherwise you have to think about what happens for a user on every old version of the DB and how they'll get to the latest

What I described what simply how to get SQLDelight attached to an existing DB at a specific version. Even if you do that, you probably need to port your migrations in case someone wasn't already on the latest.

Right 🤦‍♂️ Does SqlDelight set the

user_version

pragma? If yes I guess I could wrap the migrations with a check to see what version the user is already up to.

A normal SQLiteOpenHelper is used

Looks like

SQLiteOpenHelper

does write out the

user_version

! Thanks

I’ve created a new GitHub repo called okhttp-icu that’s intended to be a child of the existing okhttp repo. It takes a very tiny subset of the ICU project (currently one function) and packages it as a Kotlin-Multiplatform library. This new project is small but also incomplete. There’s no tests! And it isn’t actually doing meaningful expect/actual things yet to be a proper multiplatform library. I plan to hook into the built-in ICU features on all the Kotlin platforms that have 'em. Currently I only expect Kotlin/Native on Linux to use the packaged ICU; everything else should be able to get something from the host platform. It’d be nice to eventually get somebody (JetBrains? ICU?) to take this over and build a proper ICU library for Kotlin/Multiplatform. In the interim this works to unblock OkHttp’s very minimal needs.

Is https://github.com/cashapp/paparazzi/issues/706 going to get fixed with 1.3.0, or is it blocked by something?

I'm having an issue with KotlinPoet and I can't seem to figure it out. I'm trying to build a statement that uses a number of extension functions and the problem is with the

alloc

extension function. On some classes it manages to "find" and "import" the alloc extension fine, while on other classes it does not, and it generates something like

Box(nativeHeap.kotlinx.cinterop.alloc<,,,>().ptr

. Any idea what could be the reason for the member not being recognized in some classes but recognized in others? Any tips on debugging this?

The release description for version 2.0.0-alpha01 says

We expect more ABI breaking changes to come so don’t publish any libraries with dependencies on this release

Should we still avoid it with version 5?

I have a small question about SQLDelight patterns. If you have multiple views that need the same data from the DB, do you query it multiple times or do you share that data? If sharing, is there a pattern to share a Kotlin flow in multiple views and avoiding coupling?

I would query multiple times. Best to keep everything separated.

Sounds good! Another question: for simple cases I query one statement from the sql file and call

asFlow()

. Now let's say the repository is doing some non trivial processing from a database query, maybe calling itself recursively and adding one or more return values from the result (all from the same table though) - how do I wrap my final list into a flow that will refresh itself? Is there a way I can manually create a flow that refreshes from on a given table?

I may be misunderstanding you here, but if you are reading it as a flow, and are maybe doing a

mapLatest

on it which in that lambda you’re doing all this processing, if the DB emits a new value into that flow, your previous calculation should be cancelled and you will get the fresh data automatically.

Are there any plans for square/cashapp libraries to migrate to the Kotlin DSL? If not, is it something that could happen in the future? https://kotlinlang.slack.com/archives/C0922A726/p1681918323316619

No. I'm sure we have some projects that have migrated and others that will of their own accord. But there's very little reason to make such a migration in 100 projects.

I will be the last to migrate. I'll go so far as to say there's very little reason to migrate any project. You're much better served by full Kotlin convention plugins applied to Groovy buildscripts.

+1 to convention plugins with groovy buildscripts

Even for new projects?

personally yes thats what i would do

Interesting. I've been using the Kotlin DSL pretty much since the beginning, so I've felt the pain of it maturing, but it's definitely in a much better place now. I never really liked the dynamism and "magic" of groovy, and it's always a pain for me when I'm contributing to projects that use it.

personally: being able to directly copy-paste between build and plugins as I figure out what build logic to share puts me 100% in the camp of Kotlin build scripts

I feel similarly about the .gradle.kts, it has its own special magic that I find difficult to contribute to. Even in normal kotlin I hate massively DSL focused APIs that are all like

test {
  that {
    my {
      juice {
        is (yummy)
      }
    }
  }
}

I hate them both, and I hate that we've been given both as fully supported options for so long that now there's division

I'm sure its better now

the Kotlin DSL would be much more palatable if they had not gone overboard with trying to be cute and retain the feel of the Groovy DSL

that and it's still always going to be bonkers to gate the success of compilation of the file on statically parsing a code block at the top

fragmented documentation and APIs were massively frustrating earlier on for me as well. Any time I wanted to get custom with my build logic I could only find groovy APIs with no gkts equivalent

i'm sure it'll be fine in like 10 years. we also waited a decade to migrate many projects from Maven to Gradle. It's simply not a place where anyone wants to spend time on projects where time is already fleeting.

hell, we still have some and i still have to occasionally release them