yes. SQLDelight's parser is more strict because then we don't have to replicate the rules of parsing which are pretty wild if you read how it works (and may vary by version).

Does SqlDelight 2.0 have a new namespace?

Yes, everything is in app.cash.sqldelight now

I see that you have r2dbc as one of the drivers, but I can't find docs on how to use it instead of jdbc, is this not yet supported?

Someone else will have to answer. I suspect it's setting async=true in Gradle and then depending on the artifact for it. No idea how it gets set up.

Basically you have to set

generateAsync = true

in your sqldelight config. Setting up a driver is similar to JDBC where you pass the R2DBC driver an R2DBC connection and then for all your actual database operations you have to either add

.await()

to the end of your call or using an

.await*()

extension helper (e.g.

.awaitQuery()

) The one catch is that the only supported R2DBC driver right now is MySQL

We're using MoshiX's moshi-ir. Can we see/decompile somewhere the bytecode to see the actual impl of an adapter? thx

There are binary incompatibilities between okhttp 4.x and 5.x (e.g. the new Kotlin friendly

tag

APIs). What is the plan here? I'm assuming binary compatibility isn't a goal? If so can/should okhttp package name change so that 4.x and 5.x can co-exist on the same classpath without resorting to shading?

Can you be more specific? I took a quick look and didn't see it.

It is a goal. Anything compiled against 4.x, should run against 5. There might be some minor changes considered safe, such as OkHttpClient not being Cloneable, and I think response.body is non nullable.

The two that we hit so far:

java.lang.NoSuchMethodError: 'okhttp3.Request$Builder okhttp3.Request$Builder.tag(kotlin.reflect.KClass, java.lang.Object)'

and

response.body

nullability differences We can work around both of these fine, you just have to be aware of the binary differences which is what brought me to my question.

The first is probably a bug

Annoyed we missed it given the api checks.

The body is a deliberate change, meant to be binary compatible, and safe for what were previously safe paths.

Should only fail for response.cacheResponse.body etc

Thanks for flagging this, I'll look into the first one tomorrow unless someone beats me to it

Feel free to ping me if you need any additional info, I'm just now investigating if we could be compatible with 4.x. It sounds like binary compatibility is a goal which gives me enough to go on

Are you sure you are compiling against 4.x?

That missing method is in 5, but not 4.

We are compiling against 5.x, the issue comes in when a user has 4.x on their classpath

That is never supported

Thanks, that answers my question.

Yep. 5.x is a superset of 4.x, and this tag method is in that superset

Also could happen if you compile against 4.10 and run with 4.5. Your compile version is your new min.

Does Retrofit support WebSockets?

No

Hi! We’re using Moshi in our project and we’re quite heavily vested and we have a number of fairly advanced custom adapters. It’s working quite well. However, there’s a new problem that I’d like to solve -- if at all possible, in Moshi. Given json like such:

{
  "title": "Some title",
  "description": "Description of something",
  "amount": 1000,
  "currency": "NOK",
  "metadata": {
    "more": "stuff"
  }
}

I’d like to unflatten

amount

and

currency

into a its own object when deserialising:

data class Item(val title: String, val description: String, val money: Money, val metadata: MetaData)

data class Money(val amount: Int, val currency: String)

Is this doable in a generic-ish way in Moshi? I’d like for that to extend to any Retrofit response object we deem worthy. If no, I guess the alternative would be the less neat:

data class Item(val title: String, val description: String, val amount: Int, val currency String, val metadata: MetaData) {
    val money: Money = Money(amount, currency)
}

which I’d like to avoid.

Hi, folks! I know it's not that nice asking about timelines for open source projects, but we are currently evaluating the adoption of Paparazzi in our (multi-app) project, and knowing when it will support application modules will help us greatly in taking a decision. Does anyone have a vague idea of when can we expect the resource loading mechanism to be rewritten? Is it weeks, months? Thanks!