[MUSIC PLAYING]
DANIEL SANTIAGO RIVERA: Hi.
My name is Daniel Santiago, and I'm here
to talk to you about database migrations with Room--
not a Compose talk.
All right.
To start, not every database needs to be migrated.
So just letting that out.
If the data on your app is some sort of cache
or if the source of truth is your server,
then there might not be a reason to perform a database
migration.
For these cases, the Room can simply recreate the database
when the app gets updated and you
can enable this via the fall back
to the DestructiveMigration API in the builder.
However, and this is the important part,
if the data on your database is indeed a source of truth,
then it is very important to perform that schema migration,
because otherwise it can be a very unpleasant experience
for a user to update their app and to lose it.
So how do we get about doing that?
Well, with Room, it can be quite easy.
In Room 2.0, you can take advantage of Auto Migrations.
You simply define the from and to versions
where you want to migrate.
Room will look at the schemas, analyze it, and create
a migration implementation.
It's important to know that exporting the schemas
is mandatory for Auto Migrations to work.
Auto Migrations can handle most things out of the box
without any additional input, adding new columns,
adding new tables, changing foreign keys, indices,
and views.
However, there are certain cases where Auto Migrations need
a little bit more information.
In this example, there's a table rename,
and Room is looking at these two schema files.
And it can't quite really tell whether a table got deleted
and the new one with suspiciously similar columns
was created.
For these type of cases, what you can do
is provide a migration spec.
And in this migration spec, you can annotate it
with one of these annotations to help resolve
this ambiguous situation.
There's four total annotations you can use--
RenameColumn, RenameTable, DeleteColumn, and DeleteTable.
The other cool thing about Auto Migrations
is that Room will actually take the old data from the old table
and transfer it to the new table.
But be aware that there might be certain schema changes where
you might need to do a little bit of extra processing,
and you can do that on PostMigrate
in the migration spec.
And one example of that here is if we
had a column that was a Boolean and we
were trying to change it to an enum-like string, where
we changed the affinity-- for these cases
then you can implement that on PostMigrate
and execute some queries to get your data where
you want it to be.
Now, if data processing needs to happen before the migration,
then you can use a manual migration
with an auto migration.
And since manual migrations and auto migrations
are compatible with each other, you
can have them back to back to perform two version bumps.
The idea is that in your manual migration,
you perform the necessary data changes in preparation
for that auto migration.
I'll give you an example.
One example of this is if you had a table
and you wanted to add a new foreign key,
but the child table has invalid references to the parent table.
So what happens is, if you were to add the foreign key,
a foreign key constraint failure will occur.
So what you do is, in your manual migration,
you write the necessary queries to sanitize the data
and get it ready for that auto migration
to then add that foreign key.
Some migrations are just easier when
SQLite is there to help you.
For example, if you add a new column that is not known,
then you need to provide a default value.
And you can do this with the column info
so that when Room migrates the data,
it fills the existing rows with the default data
that you specify.
Nice.
So migration bugs are not very common,
which means that it's an area often overlooked
during testing.
But it's really important to test your migration,
because they can lead to some really bad bugs.
Especially, they tend to lead to databases and apps
getting into a crash loop, because they're
trying to update the database and failing.
And the user ends up reinstalling the app,
and they lose their data.
It's not great.
The good news is that Room does offer APIs
for testing migrations, including auto migrations.
And our recommendation is that you write a test
for each version that you do.
It's also good to put some data on the database
so that you can then verify it.
To do this, you use the Migration Test Helper API,
and it will enable you to create the database at an older
version.
You put some data in it, and then you
use runMigrationsAndValidate to go over manual Migrations
or auto migrations.
And then you'll get a database that
has been migrated, validated, and then
you can verify the data on it.
So runMigrationsAndValidate will also find those auto migrations
for you.
And that's really it.
Thank you so much.
You can find more information in that link over there.
And that's it.
Thank you.
[APPLAUSE]
[MUSIC PLAYING]