Destructively migrate on library downgrade [110416954]

Fixed

Feature Request

Status Update

No update yet.

Description

ku...@gmail.com

created issue #1

Jun 20, 2018 12:25AM

If I migrate my app from version n to version n + 1, the underlying database gets migrated too. If I then checkout a different branch or want to downgrade WorkManager later, there is no database migration path from n + 1 back to n.
It is preferable to have a destructive migration to crashing the app.

Comments

su...@google.com <su...@google.com> #2Jun 20, 2018 03:51PM

This is a Room feature request, not one for WorkManager.

ku...@gmail.com <ku...@gmail.com> #3Jun 20, 2018 04:57PM

WorkManager needs to add a destructive 2 to 1 migration.

su...@google.com <su...@google.com> #4Jun 20, 2018 05:00PM

The way we're thinking, if a downgrade isn't specified, it should be destructive by default in Room.

yb...@google.com <yb...@google.com> #5Jun 20, 2018 09:12PM

Assigned to da...@google.com.

i think it makes sense for downgrades, at least we can make this another flag.

ia...@gmail.com <ia...@gmail.com> #6Jun 20, 2018 09:15PM

Would it be possible for WorkManager to use the currently available fallbackToDestructiveMigration() method for its database until the Room API is built and available in a stable release? It should be possible to manually check the forward migrations to make sure they are covered.

yb...@google.com <yb...@google.com> #7Jun 20, 2018 10:54PM

actually it could have a dummy migration for +1,+2,+3,+4 versions that does this destructive migration manually.

da...@google.com <da...@google.com> #8Jul 9, 2018 11:51PM

Marked as fixed.

This feature will be available in Room 2.1.0.