I’m not aware of any json support at all

I don’t think it’s there

It is something we want to add for the 2.0 release!

Oh I see the json type

Yea no reason it’s not there

thanks!

Do I understand correctly that when using SqlDelight in multiplatform, then schema management is a bit asymmetrical in that android driver manages schema creation + upgrade/migration for you, while for other platforms (jdbc driver specifically) one must write this code manually? Or did I miss some helper class?

Follow up question: where is the schema version stored in the database in Jdbc case? UPD: Found this issue which answers all my questions 🙂

Is it normal that I see runnning this task even in a project that has no SQLDelight dependency or usage?

yea, that task is also how it figures out sqldelight is not configured, but i think we can avoid it so will hopefully fix that in next release

line 2:7 - TO expected, got 'COLUMN'
1    ALTER TABLE MY_TABLE
2    RENAME COLUMN field1 TO field2

Am I missing something? I though https://github.com/cashapp/sqldelight/issues/1505 would have fix this? I’m using sqldelight 1.5.2

Network interceptor sees all, especially if it's last in the chain

unless there's an earlier interceptor that skips the chain, I guess

You cannot

You either early return in which case a proxy would never see it or you forward along the chain to hit the network

wasn't one of the suggestions for HTTP/3 support to implement your own interceptor that would perform network operations on its own?

in that case, a proxy would see it, but a later interceptor wouldn't

Awesome. I will suggest that the docs for this library move towards a network interceptor. https://github.com/ChuckerTeam/chucker/issues/759

I'm putting together a cheat sheet for how moshi will deserialize values into your defined model depending on how your model is defined (i.e. trying to highlight, that you can have a String defined that gets a number from json, and it will indeed work/convert the number to string) So here's the silly part, when it comes to modelling a String, how many different ways could you write a field called

name

that's a String? Just 5, right? Or are there some other annotations or something that could change the result?

val name: String = "default"
val name: String? = "default"
val name: String? = null
val name: String?
val name: String

My intent in the cheat sheet is to show "Hey if your field is defined like this, and your backend sends "foo", explicit null, or omits the field in json entirely, this is your result."

If there's a qualifier annotation an adapter could also impose its will on the value

Sometimes I think moshi would just be easier with java models

Definitely true

Java’s worse. In particular, Moshi+Java creates instances without constructors which creates the opportunities for really surprising code.

class Payment {
  String currency = "USD";
  long amount;

  public Payment(long amount) {
    this.amount = amount;
  }
}

Moshi decodes

{"amount": 100}

to a

Payment

with a

null

currency! We’re doing nasty things because Moshi works field-by-field and there’s no nice way to map field names to constructor parameter names.

Moshi Kotlin’s way better. The opportunities for differences between absent & null is annoying, but that’s more JSON’s fault than Moshi’s. When you decode JSON to a Kotlin object with Moshi, it just calls your constructor with the arguments you give it.

`{}`                  --> same as calling `Person()`
`{"name": "Colton"}`  --> same as calling `Person(name = "Colton")`
`{"name": null}`      --> same as calling `Person(name = null)`

Records solved that mapping problem

Very interesting! This stuff is kinda mind blowing how complex it is for a seemingly simple problem. this talk is still amazingly helpful. But the more I hear about these weirdnesses in how things are deserialized the more I think why there isn't like a chart on each major repo (gson, jackson, moshi, kotlinx) showing how things deserialize. lol Creating this little cheat sheet for myself has been amazing helpful (thank goodness for mockhttpserver for letting me quickly test these scenarios in unit tests)

If only my backend team actually adhered to the models/optionality/nullability they describe in the docs. so in a lot of cases... things are decalred as never supposed to be null, but then a null comes down. web and ios are good to go. android crashes. 😭 I can only think that the solution is to just make everything nullable in my network models.

Okay. I think I'm going crazy. I swear Moshi would "*allow*" (not crash) deserializing an explicit null from json into a non-nullable val. And then you would be able to continue with your application, until you used that property and then you found out it was actually null and your code would crash. But now that I'm writing tests against, it... it seems like moshi crashes at the sight of null if the property is non-null. Could it be something else, maybe I'm mis-remembering?

That's from before Kotlin support when it wrote to backing fields

@alec I’m using sqlite for a server project with postgres. I’m trying to weigh whether I should use flyway or sqldelight built in migrations. Something I’m not sure of - The documentation for migrations says:

The 

.sq

 file always describes how to create the latest schema in an empty database.

Is this something that sqldelight will verify for me, or is it up to me?