Improve reliability of upversioning process (update shim)

[githubbob42]

Mingle Card: 3356 Narrative

The current upversioning logic is a disjointed rube-goldberg machine. Fill necessary gaps in the latest indexedDBShim so we can reliably control the upversioning process.

Acceptance Criteria

Upversioning should be more reliable. In particular, iPads should more reliably perform upversioning without crashing.

Analysis

The current upversion flow goes like this:

1. App loads javascript
2. Individual stores immediately start creating databases. We currently don’t control this flow. It all happens as individual modules are loaded.
3. If a database exists, it immediately/automatically checks to see if it needs to upversion
4. If an upversion is not needed, the database is created/opened
5. If an upversion is needed, the current database is deleted
   1. the db is deleted because the old shim doesn’t support deleteIndex() so the only option is to delete the database and recreate everything. Otherwise we can be left with invalid indexes.
   2. the db is deleted within the transaction meant to handle upversioning
   3. because we delete the database within the upversion transaction, the result of the original request for the database is a closed connection to the original database
   4. if any other module has already loaded and grabbed a handle on the database, it’s left with a closed database connection
   5. we don’t explicitly control the order/speed in which modules are loaded into memory so we’re left with a race condition
   6. if a module is left with a closed connection, the iPad will hang as it waits for the dead database connection
6. All of the above occurs before we even get to the sync process…
7. Lookup sync doesn’t know if a schema change has occurred, so it always does an incremental sync
   1. this means we can have incremental chunks of records in the database that’s missing columns
   2. we can’t take any proactive actions anyway because the upversion/maybe-delete process currently occurs automatically

The new upversion flow goes like this:

1. App loads javascript
2. No databases are automatically created because it’s behind a getter
3. No databases are deleted during an upversion process
   1. we now use deleteIndex() to delete existing indexes and recreate them
   2. standard upversion process is now safe because we don’t prematurely kill the transaction by deleting the database
   3. there is no code path where just loading a module will trigger the deletion of a database
4. During Sync:
   1. Transactional databases are deleted during red sync. This is safe because the reference to a db is behind a getter which will recreate the database the next time something needs it.
   2. Lookup queries continue to do an incremental sync
   3. We can detect if an upversion is needed BEFORE we start writing to the database for lookups so…
      1. if we know that a schema change has occurred, we delete the current lookup database and force a full sync (not an incremental sync)

Related Stories

Tasks

{{table query: SELECT Number, Name, Owner, 'Task Status' WHERE Type = Task and Story = THIS CARD}}

Defects

{{ table query: SELECT Number, Name, Owner, 'Status' WHERE Type = Defect and 'Related Story' = THIS CARD }}

Test Plan

Run entire automated test suite using the shim

Upversion on desktop and iPad

Smoke tests to verify we have no regressions in application behavior due to updated shim.

- keyword search

- paging

- reference picker filters

- service types

[githubbob42]

Feature: #2993 Tablet Performance (Mingle)

[githubbob42]

Pull Request #1568