tree c51062746e2c893a60d457077fc8eb388ef0ae39
parent 9fcd3c9e07dfe9167a198954763676a8084d51c6
author Elif Bilgin <elifbilgin@google.com> 1623006125 -0700
committer Elif Bilgin <elifbilgin@google.com> 1623006125 -0700

Resolving issue of improper handling of indexes in auto migrations.

Fixed two issues in this CL:

1) When a brand new table is added in the new database version, only the CREATE TABLE statement was used in constructing the new table. This was an invalid approach as the CREATE TABLE SQL statements do not include the statements required to create the indexes associated with this table. Therefore, even if there were indexes in the new table, the statements for adding them to the table would not be added in AutoMigrationWriter. This issue was only valid for the case of indexes, as foreign keys are included in the CREATE TABLE statements, and views are destroyed and recreated by our implementation independent of CREATE TABLE (regardless of any changes).

2) When we check for new added columns, we have logic in place that avoids processing any new columns detected in a table that has already been discovered as a "complex changed table", as this table will be destroyed and recreated from scratch already, and the new added columns will be handled automatically in this process. In the previous logic, we were conducting this check by looking up the name of the "toTable" in the map of complex changed tables. This was incorrect as the map is keyed by the table names in the "from" version of the database, therefore if a table was renamed and included complex changes and had a new column added to it, this check would fail (as the table would not be found in the map).

A new Entity has been added to AutoMigrationDb to check for these cases.

Bug: 189726437
Test: AutoMigrationTest.java
Change-Id: I2554abe0e5ea2d5c5031ab6112862c25b7d5879c