Design

Overview

Problem: Update architecture for FIP-1 to include the ability to page and cache data on wallets

...

• Removal of the Ledger

  • The purpose of this ledger was to quickly search ids but this limited CPU processing time for high volume users when needing to append or modify the vector container due to serialization.

• Additional searchable indexes inside the fiotrxts table.

  • 

    These index searches allow for multiple queriable conditions inside a single, bit shifted operation. This also allows future development to search by status(es).

  • New global data member, STATUS_MULTIPLIER is used for shifting operations.

• New time index search inside fiotrxts table.

  • 

    This will allow time-based state cleanup in the future.

Functional Testing

Design

• Overview of test plan with high-level bulleted test cases

...

• Link to JS tests and description of which test sections were updated/added

• Paste results of tests

Performance Testing

Design

• Overview of test plan with high-level bulleted test cases

...

• Summary of performance tests that were run and results

Fork Testing Plan

This is not a forking change since users on current chain code and new chain code will maintain the same state. What changes in the new chain code is how the FIO Request getters work. In the current code, they call into the current tables. In the new chain code, they will call into the new tables. So, wallets that point to an API that has not upgraded will eventually get null data once we fully transfer over to the new tables and delete the old ones. We will maintain both tables for a time, but at some point we will do a contact msig that deletes the old table. So, we do not need a date in the chain code, the break will come when we do the msig.

Rollout/Release Plan

Release 1 - fio.contracts (Bravo-c1)

After this update and the initial call to migrtrx, new Request and OBT data coming in will be entered into both the old and new tables.

Step 1 introduces the new table structure and adds a new “temporary” action call called migrtrx. This action enables the top 21 block producers to start migrating existing data over to the new formatted index tables.

...

[FIP-1.b] Step 1: Add continuous migration of request and obt data (FIO #182)

The complete migration of data has to happen before fio chain is released. An off chain validation should be done to confirm this.

Release 2 - fio chain (Bravo-chain)

...

Release 3 - fio.contracts (Bravo-c2)

All fio chain nodes should be upgraded prior to rolling out Contract Step 2.

Step 2 does two things:

• Modifies the Request code to stop updating the old tables. After this release, only the new tables will get updated.

• Modifies the  migrtrx call. It will now remove data from the old tables.

...

• New OBT and Requests will be put into the new tables.

• Get requests and OBT getters will get a 500 “Error 3060003: contract table query exception” error.

Release Verification Plan

Casey Gardiner Need this. Add info on your scripts that will verify data, etc.