I'll be the Devil's advocate here 😉

Even though I have some good background in SQL, I really dread migrations. They are really tasking. So it would be definitely great to have this just for convenience.

Beyond that, i think we can just tool migration better. If you invoke the rename refactor on a column we can automatically produce a migration. If you invoke rename refactor on a table we can automatically produce a migration. If you change a column type we can warn that you need a migration. If you add a new table we prompt you to add it to a migration. And so on...

What’s difficult about writing migrations? 99% of the migrations I’ve written have been pretty simple — like deleting a column or adding a table. Anything that’s sufficiently complex auto migrations from room wouldn’t be able to handle, anyway

And when I say simple, I mean I literally copy and paste table definitions from the updated schema a lot of the time

I wouldn't call deleting a column simple

At least not before the latest release of sqlite.

OK I see the challenges. It's true that the implementation by Room is limited and not perfect. And the points here raised are valid. I guess its best to stick to SQL.

Thanks this is helpful

Let me be clear, I’m not trying to shut you down 🙂 I was genuinely curious what you thought was difficult about migrations. In my experience, migrations have only been difficult when they couldn’t be completed with pure SQL. I was wondering what your experience was

knowing specifically which things are hard or trip you up is helpful. for example, writing code to assist migrations was historically much harder than it needed to be. the latest release adds a really straightforward mechanism to attach code migration callbacks: https://cashapp.github.io/sqldelight/android_sqlite/migrations/#code-migrations

I think some of the tooling improvements would be a welcome surprise. Sometimes we forget to write migrations or do them the wrong way. Like the verification tool is great. I hadn't used it before.

I once used Flyway + Exposed for Postgres DB in a Multiplatform project. SqlDelight for postgresql wasn't very mature by then not sure now. If my memory serves me right they would save you by generating some migration SQL code in the error message each time you forget to add migration. So it was kinda easy to then copy the code and add it to a migration.

Maybe that could be added as output to the

verifyMigrations

task?

That would sure be helpful to identifying problems in CI, as well

Love the Eminem reference in the Kotlin Poet ,documentation 😆

In SQLDelight is there a way to make the

verifySqlDelightMigration

task not care about the ordering of columns? I’d like to use it to verify schema changes but the strict column ordering would force me to drop tables and recreate them when adding a column rather than using the simpler

ALTER TABLE

statements.

Consistent column ordering is required for SELECT * to work

i just always add columns to the end of my table and then you can do

ALTER TABLE ADD COLUMN

and it will work

IR has been supported since 1.4.2

com.squareup.sqldelight:coroutines-extensions

seems to be only sqldelight dependency it's complaining about fwiw

hello, i have a question about sqldelight. What is the usage of code migrations for android and what differ from sq migrations. The documentation is a bad example i think, because you can do exactly the same thing in .sq files. So what is the advantage ?

You would do a code migration of the days being worked on was only in kotlin

I mean

Really anything that you can't do in sql

In retrofit... when I don't really care about the type coming back. I just care about checking whether it was a 200. How would I write that? I believe in Java I would use Response<Void>, but I'm using kotlin + suspend functions. Not sure if that changes anything. Is something like this alright?

@GET("api/logout") suspend fun logOut(): Response<ResponseBody>

yep that's fine. downside is we buffer the response body in memory. Void is better. there's a tracking issue (or maybe just a TODO) about supporting Unit.

So by using

Void

I forfeit the ability to inspect the responseBody at all, while using

ResponseBody

still technically gives me that ability? Or are both of them basically the same, but Void never buffers the response body so it's "better"?

In sqldelight, if i store a date and create a converter for it (LocalDate for instance). then in my query, i do something like: “SELECT * where date(:date, ‘unixEpoch’) …“, the date argument gets generated as Long, not as LocalDate. I’m guessing this is expected, because there is really no way of inferring the type. OR i am wrong, and this is something the parser could be improved on ?