There is no built-in migration, but you can use

deriveSchemaFromMigration

, and create a

0.sqm

file describing you init schema, and put your changes in

1.sqm

etc. The sqldelight compiler can validate your migrations.

@jessewilson Do you guys use sqldelight on your server?

YES

Is there a way in sqldelight to just let me put in some raw SQL, and have it ignore any syntax issues that it might think are there? i.e. I can’t use the

DATE_ADD

function with the

INTERVAL

syntax, because it shows a type error:

INSERT INTO PendingInstallation(
    id,
    verification_code,
    expiration
) VALUES (
    UUID(),
    UUID(),
    DATE_ADD(now(), INTERVAL 2 HOUR)
);

It seems unreasonable for me to expect that sqldelight can just magically support every nook and cranny of the mysql dialect, and I really enjoy the typesafety it gives me on SELECT statements, and the parameter names etc on other statements, but I feel like most of the interesting things I’ve been working with today, I’ve spent time trying to work around using mysql features that sqldelight doesn’t seem to support.

The compiler (sql-psi) does not support this syntax and is unable to generate the code and to perform the validation. Only workaround is moving the sql code to your Kotlin code and call

driver.execute

... You could add your syntax to https://github.com/AlecStrong/sql-psi

Just to check - sqldelight can’t verify migration schema outside of sqlite, right?

correct

Would you accept a PR removing the toString implementation? https://github.com/cashapp/sqldelight/pull/1117 It seems it was only driven by the fact in the early days interfaces + data classes were generated but nowadays the built in toString should do it and the codebase would become a glimpse simpler

I don't think it meaningfully contributes to the complexity since it's not that complex. No one has had to touch it in 3 years, for example.

If you can provide before/after comparisons we can discuss in an issue, but I remember we were dissatisfied with the regular one.

it was just because everything used to be named

Impl

we could probably get rid of it

if it makes tests smaller I’m all for it, since those are typically where we pay for refactors

the only other advantage to our custom print is that its formatted with newlines and i dont think data classes are

but, meh

Do data classes do contentToString?

To me if code doesn’t have to exist it shouldn’t exist. I don’t accept the argument that because it’s working it shouldn’t be touched 😛

Nope, no contentToString

But if you have an array in a data class that’s bad anyways and it should rather be generated as a class to prevent people from shooting theirselfes in the foot

Ah it apparently handles it, only not using contentDeepToString

i didn't say it shouldn't be touched. i argued against your assertion that it contributes complexity by pointing out that it hasn't needed to be touched. contrast that to the logic that deals with actually understanding queries which is constantly being refined because it is actual complexity.

Every single line of code contributes to the overall complexity. When someone looks into a class everything contributes to the cognitive load. Having x functions and y test cases less keeps more room for focus on the meaningful tests + functions

if it means this conversation can end, please submit a PR

That was my evil plan from the beginning😈

I either have a dagger issue or a okhttp issue so I figured just tossing the question out here would be fine. I have an okhttp authenticator

RefreshTokenAuthenticator

that on a 401 calls

myApiService.getNewAuthTokenWithRefreshToken

to trade in a refresh token for a new auth token. My dependency graph looks like this:

RetrofitService

->

OkHttpClient

->

RefreshTokenAuthenticator

->

RetrofitService!?!?

Do I have a legitimate use case for Lazy in dagger, or should my Authenticator not be calling my apiService?

Use Lazy

or move token refresh to another service, since if that 401's there's no point to intercepting it to re-invoke recursively?

Thanks! If anyone is familiar with Authenticators and wants to do a sanity check on mine that would be cool. Early results while hooked up to charles proxy are all looking good.

so you're adding the Authorization header in an interceptor? I don't think this works, as the authenticator is called after all the interceptors, so after it runs you're returning the original request with outdated access token, which won't be re-intercepted to add the new access token. you should update the Authorization header in the returned request

Ooh. I think you're right. I was testing more with charles and it seems like my re-run of the original request that caused the 401 actually still uses the old Auth. I replaced it with this

return response
        .request
        .newBuilder()
        .header("Authorization", "Bearer: ${appUserManager.authToken!!}")
        .build()

and we seem to be back in business. I thought it re-ran the request again, which would call all of my other interceptors again (which would have given the request the updated token) but it instead seems like it just runs that request identically to before. So with my change above, I think we're in a good spot.