and it helps protect against rebase issues

We also use this approach as Alec suggested, we have appname-db which aggregates all db modules required for appname and only it have migration files for this app, so db modules are app independent, you may use them for different apps

https://github.com/square/retrofit says:

If you are using R8 the shrinking and obfuscation rules are included automatically.

ProGuard users must manually add the options from retrofit2.pro. You might also need rules for OkHttp and Okio which are dependencies of this library.

https://square.github.io/retrofit/ says:

If you are using R8 or ProGuard add the options from this file.

You might also need rules for OkHttp and Okio which are dependencies of this library.

Worth filing a bug on the difference? Also, does anyone know which one is right (im in the middle of enabling R8 for the first time on a huge project)? I'm assuming that using R8 doesn't require the options from the file linked.

You shouldn't need to do anything. It's all bundled

Hi guys, I’m curious with a crash in

okHttp4

which I faced only in release environment when

minifyEnabled

and

shrinkResources

are enabled.

Fatal Exception: java.lang.IllegalStateException: cannot make a new request because the previous response is still open: please call response.close()
       at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.java:223)
       at okhttp3.internal.connection.RealCall.enterNetworkInterceptorExchange(RealCall.java:223)
       at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:66)
       at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:100)
       at com.pocketaces.locostudio.network.interceptors.OAuthInterceptor$intercept$1.invokeSuspend(OAuthInterceptor.java:111)

I know the reason and I have fixed the cause but still wondering why this crash don’t come in debug environment.

Fix is to close the response body in your interceptor

currently trying to use sqlite + jvm with

deriveSchemaFromMigrations = true

the migrations writing works but files with queries says the tables don't exist and highlighting is broken

anyone who has this working and a project where it keeps working ? i am thinking maybe this is a regression because idea version change.. because this used to work in my code a month ago and there was no changes

I have the same problem NikkyAI is having. I have found a rather silly workaround... I can cut-and-paste a query from the .sq files to the latest .sqm migration, where completion and error highlighting work correctly. In this state, the project does not compile successfully. Once I get the queries correct, I can cut-and-paste them back to the .sq files where they belong, where completion and error highlighting in intellij fail, but the project compiles correctly via gradle.

might be related to the gradle/intellij versioning. I’d make sure both plugins are on 1.4.3 of sqldelight. After that I’d try the latest snapshot IDE plugin, that’s working for my MySQL/deriveSchemaFromMigrations/jvm setup. If that still doesn’t work, can you file an issue and include general project layout (where .sq and .sqm files are, where build.gradle files are, what sqldelight {} block of build.gradle looks like) and I’ll try to recreate a repro. If you’re able to make a small repro yourself please link that!

I'm currently on 1.4.3 for both sqldelight itself and the intellij plugin. I will see about finding a snapshot of the plugin to try. I can make a stripped down version of the project as a test, if that doesn't work!

🙏 thx

snapshots are in the EAP channel: https://plugins.jetbrains.com/plugin/8191-sqldelight/versions/eap

i am using

1.5.0-SNAPSHOT-1601055432366

and i am having the issue and using 1.5.0-SNAPSHOT for the gradle plugin ofc

also does it happen consistently? if you restart the IDE is it still a problem?

so far it is

TIL about

deriveSchemaFromMigrations

, is that mentioned in the docs anywhere?

It is for PostgreSQL, MySQL, and HSQL in the Gradle section, but for some reason it's not on the SQLite Gradle section (native nor JVM) 🤔

It’s a pretty abnormal idea for android and we haven’t implemented schema squashing which I would want to implement onCreate in the SupportSQLiteOpenHelper, so I mostly just left it out to avoid confusion

But creating a fresh database in server land isn’t a thing, there’s only one database (ish) that you’re only ever migrating

So having a sane onCreate doesn’t matter

Also it’s just what server developers are used to

But I do think it’s the future of SQLDelight

And we just kill static schemas and only have migrations

No more duplication!

Just need to battle test it more

Ye ye yea I remember doing this when I was learning Rails

Having a single source of truth for the schema is so powerful

and it forces people to do the right thing by writing migrations