Fixed
Status Update
Comments
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #2
do you want to drop all tables or truncate all tables?
i think we can generate a method that does that in RoomDatabase.
i think we can generate a method that does that in RoomDatabase.
ap...@google.com <ap...@google.com> #3
I was also looking for this and could not find it. For me it would be ideal if it could drop the whole database. So when the user logs out everything is cleared and the new database is then created on a new log in - the same as if running the application for the first time.
il...@google.com <il...@google.com> #4
you can consider closing and then deleting the database. (context.deleteDatabase).
The only difference vs truncating would be the auto-increment ids would be reset. Is it that important?
The only difference vs truncating would be the auto-increment ids would be reset. Is it that important?
Description
Component used: Lifecycle
Version used: 2.5.0-alpha01
Currently the call to
enableSavedStateHandles()
creates aViewModel
using theViewModelStore
. This requires that the ViewModelStore be set on any component attempting to make the call, but there are scenarios where the call toenableSavedStateHandles
needs to happen before that in particular in the Fragment and Navigation components where the call is not immediately made when the object is constructed or sometimes not at all.If we remove the reliance on
SavedStateHandles
(and therefore view models), we can lean into theSavedStateProvider
APIs and the call toenableSavedStateHandles()
can be made before theViewModelStore
is set.