Okio’s FileSystem supports random access to files. Individual buffers don't.

Last day for OkHttp 3.x. https://square.github.io/okhttp/security/

Sqldelight

1.5.3

generates the following code in

DatabaseImpl

and compilation fails with `Unresolved reference: _value`:

public override fun select_default_with_query(`value`: String): Query<UserWithSubscripiton> =
      select_default_with_query(value_) { id, username, avatarTemplate, email -> ... }

Query is like this (simplified):

select_default_with_query:
SELECT *
FROM UserWithSubscripiton
WHERE username LIKE ('%' || ?1 || '%') OR email LIKE ('%' || ?1 || '%')

I copied it from the project with older sqldelight version where it worked. Is this a bug or am I doing this wrong somehow? Oh, and this is a KMP project now.

switched to named arguments, now it works.

`value` != value_

is probably the problem and I think that's a bug worth filling.

Ok, will try to create a minimal project then.

Or even just the offending query

done: https://github.com/cashapp/sqldelight/issues/2759

Yes this is expected. https://javadoc.io/doc/com.squareup.moshi/moshi/latest/moshi/com.squareup.moshi/-json-reader/next-string.html

(…) If the next token is a number, this method will return its string form.

Interesting. Thanks! A lot of my projects use firestore and the parsing that happens there will crash if a number is encountered instead of a string, and so I was just drawing parralells to that world. Thank you Michal for the docs reference!

Hi, a question about retrofit - my api supports multiple date formats, is there a way to pick the relevant one when parsing json?

retrofit is not involved in this

consult the documentation for your chosen JSON serialization library

they all have ways to do this, usually with annotations that specify the format or specify a serializer, or disambiguation which serializer applies to which property, etc.

SQLDelight: I have 2 select queries with different where condition. Both queries return the same attributes. Is there any possibility to get the same type? Currently the resulting types are

GetA

and

GetB

, two identical classes.

in SQLite I would use a view for it

i like that option because you also get to control the name of the shared class and it should hopefully also simplify the queries themselves

the other option is to use the mapper overload of the query function:

val getA = myQueries.getA("some parameter")

val getB = myQueries.getB("some other parameter", ::GetA)

Uh, nice, thanks!

That also consumes the body so you probably want to peek it

Perfect thanks! Going to check this

I have an ApiService written in retrofit. It has about 20 calls. 15 of them require an authorization header. 5 require explcitly NOT sending an auth header. I'm already using an interceptor, but it's getting applied to each of the 20 calls. Should I just opt out in my auth interceptor itself, or should I write an annotation to opt out or something? My fear of just going the interceptor approach is that it doesn't require a dev to make a concious decision when adding a new api call. You gotta run the app. Potentially wait for the call to fail, and then know to go update the interceptor to add to the allow/deny list.

I'd create two separate services, keeping must-auth separate from must-not-auth

I also considered that (that's how my last team had it set up), although with this new app it was sorta convenient to just have one. Curious if anyone else had experience with it, or even had situation where auth header was optional (i.e. maybe a reset password network call or something)

individual calls can have

@Header("Authorization")

parameters. I think you should be able to pass a User object there, and register a converter from User to header string, and have it all work out? haven't actually tried that though

I have to double check, but I'm pretty sure I added a "fake" header that my interceptor looks for, and doesn't include the auth header if it's present (and also removes the fake header)

Two interfaces certainly forces you to make a decision. It also means you can potentially make them available in different dependency injection scopes. But an annotation signaling an opt-out of the auth header is also pretty pragmatic.

Opt-in! So you don't leak credentials when you don't want to

@alec I noticed that for sqldelight postgres, it doesn’t support jsonb. I’m curious why that would be, as if you added json support, I’m assuming jsonb was left out intentionally? Is there a limitation I’m unaware of?