Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
This is a Room feature request, not one for WorkManager.
ap...@google.com
WorkManager needs to add a destructive 2 to 1 migration.
mg...@google.com
The way we're thinking, if a downgrade isn't specified, it should be destructive by default in Room.
ap...@google.com
i think it makes sense for downgrades, at least we can make this another flag.
mg...@google.com
ap...@google.com
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.
ap...@google.com
actually it could have a dummy migration for +1,+2,+3,+4 versions that does this destructive migration manually.
pr...@google.com
This feature will be available in Room 2.1.0.
Description
It would be nice if the core concepts of Lifecycle would be available for use in Kotlin Multiplatform projects.
Libraries like the Navigation Component, Fragments, etc. have all settled on the same definitions of Lifecycle States, which seem to apply to any UI:
CREATED- created, but not yet visibleSTARTED- visible, but not yet settled (e.g., entering or exiting transitions may still be running)RESUMED- visible and settledThis would include:
LifecycleLifecycleRegistryLifecycleOwnerLifecycleObserverAnd ideally everything in the
lifecycle-commonandlifecycle-runtimeartifacts.