Fixed
Status Update
Comments
ma...@caringvillage.com <ma...@caringvillage.com> #2
I've experienced seen this issue, even on 26.0.0-beta1.
da...@google.com <da...@google.com> #3
Thank you for reporting this issue. We have shared this with our engineering team and will update this issue with more information as it becomes available.
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #4
I think I'm running into this issue again--but this time it's with deep-linking and synthesizing a fragment back stack. If I have postponeEnterTransition in the fragment I'm deep-linking to, I see the other (backstacked) fragments briefly show on screen.
In one project, I'm using the Navigation Component. The graph is just two fragments: A1 is the start destination with a deep-link to A2. I see A1 show momentarily if I use postponeEnterTransition in A2. And I see similar results in another project that does its own fragment transactions; in that case, I can use setReorderingAllowed(false) to prevent the issue.
In one project, I'm using the Navigation Component. The graph is just two fragments: A1 is the start destination with a deep-link to A2. I see A1 show momentarily if I use postponeEnterTransition in A2. And I see similar results in another project that does its own fragment transactions; in that case, I can use setReorderingAllowed(false) to prevent the issue.
da...@google.com <da...@google.com>
pr...@google.com <pr...@google.com> #5
This has been fixed internally and will be avilable in Fragment 1.3.0-alpha08.
Note: this fix relies on using the
Description
I'm using:
My databases are configured with:
When a destructive migration occurs we're getting an error on Android (and I believe we're getting a similar error on iOS, but am awaiting confirmation on that).
I pulled the db from device explorer, and it looks like the "destructive" part of the migration never completed? All the tables and views are is still present - but it's all in the .wal file (first time I just pulled the .db file, and it was empty).
Clearing storage, or uninstall+reinstall resolves the issue, but that's less than ideal, and as soon as the db version is bumped again, even if no other changes are made to the code, it happens again.
It's odd that this appears to have just popped up recently, after a couple of minor changes, after appearing to have been working fine for the last ~15 or so destructive migrations.