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

It looks like we have more directories

›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/arm64-v8a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/arm64-v8a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/armeabi-v7a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/armeabi-v7a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86_64/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86_64/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/arm64-v8a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/arm64-v8a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/armeabi-v7a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/armeabi-v7a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86_64/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86_64/build.ninja.txt📋

it also considers all of these input to configuration cache

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

Prefab feature also seems to cause the following to be added as configuration ache inputs

›../../out/androidx/external/libyuv/build/intermediates/prefab_package_header_only/prefab_publication.json/debug📋
›../../out/androidx/external/libyuv/build/intermediates/prefab_package_header_only/prefab_publication.json/release📋
›../../out/androidx/test/ext/junit-gtest/build/intermediates/prefab_package_header_only/prefab_publication.json/debug📋
›../../out/androidx/test/ext/junit-gtest/build/intermediates/prefab_package_header_only/prefab_publication.json/release📋

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

./gradlew zipTestConfigsWithApks

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

Assigned to da...@google.com.

./gradlew zipTestConfigsWithApks in the androidx project

Do you mean to run from androidx-main/frameworks/support? If so, I did a run but it took too long and failed in the end with some 9 errors. Even if it finished successfully, it is too long for debug. Do we have to run that specific task or it can be reproduced with some lightweight task? If would be more helpful if we can even reproduce it in a sample project instead of using the androidx project.

Jomo, do you know where those cxx related files are being created? any pointers?

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

The easiest is to probably just look at https://android-build.corp.google.com/builds/pending/P58531861/androidx_incremental/latest/incremental/configuration-cache-reports/78r13m56v7yjbg14vhi2yg2nb/5o4wtl36u55s4qrlzmk4n19px/configuration-cache-report.html

in there see file system entry. all of these files are treated as input to the configuration cache. There should be no entries to ../../out/ once all the plugins are fixed.

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

Sadly, the report doesnt give you traces (I asked rodrigo from gradle to add it in the future version of gradle), so we only see it is coming from plugin 'com.android.internal.library'

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

Marked as fixed.

As far as I know, the most effective way to get the traces is to debug a build running with gradle by adding a break point here https://github.com/gradle/gradle/blob/8129d2feae87affd001b82ada7fa57c233f66467/subprojects/core/src/main/java/org/gradle/internal/classpath/Instrumented.java#L367 which is why we need a sample project. Other than that, we have to guess based on path name from the report.