Add resource UUID to LocalChangeEntity, fixing changing UUID issue for the same resource

[anchita-g]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Fixes #2209

Description

• We need to LocalChangeEntity agnostic of the resource ID as there can be cases where the resource ID of a resource might change (POST for creation). In such cases we can use resource UUID to keep the mapping between the resource and LocalChanges intact.
• Fixing the ResourceDatabaseMigrationTest to use the migrated database for the particular implemented migration to run assertions
• There are cases where in download of a resource which already exists in the database leads to new resource UUID being assigned to the same resource. Hence we need to keep the same resource UUID as the previous version in such cases

Alternative(s) considered
One alternative in the first scenario was to just keep the resourceUuid and remove resourceId. However, when LocalChanges are uploaded to the server, we would need to look up the ResourceEntity using the resourceUuid in the LocalChangeEntity to obtain the server recognisable identifier of the resource. This would be a problem in case of deleted resources, where in for any LocalChange of a resource that has been deleted, we would not be able to find the corresponding ResourceEntity. Hence, keeping resourceId is also crucial

Type
Choose one: Feature
Screenshots (if applicable)

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

[MJ1998]

I don't understand why the alternative solution won't work.

In case of locally deleted resource, we can remove resourceId and still fetch the mapped ResourceEntity via LocalChangeEntity.resourceUuid.

[aditya-07]

I don't understand why the alternative solution won't work.

In case of locally deleted resource, we can remove resourceId and still fetch the mapped ResourceEntity via LocalChangeEntity.resourceUuid.

For the DELETE resource event, engine removes its entry from ResourceEntity and adds a corresponding DELETE entry into the LocalChangeEntity. Hence, to sync the change to sever, LocalChangeEntity should have the resourceID so that it can be uploaded / deleted properly on the server.

[MJ1998]

LGTM

[aditya-07]

LGTM!

[jingtang10]

@anchita-g have you tested the db migration on a real device? thanks!

[anchita-g]

@anchita-g have you tested the db migration on a real device? thanks!

Hello, yes I was able to test the db migration on a real device using the demo application. It works seamlessly and I was able to see the new column in the App Inspection database explorer