Allowing the refresh_matviews script to be run synchronously.

[timparsons]

Description

Allowing the refresh_matviews script to be run synchronously.

Checklist

• Refactoring only
• Documentation only
• Fixture update only
• Bug fix
  • The relevant issue has been closed.
  • Further work is required.
• New feature
  • Relevant tests have been created and run.
  • Data was added to the fixture
    • Data was added via a patch in /t/data/fixture/patches/.
  • User-Facing Change
    • The user manual in /docs has been updated.
  • Any new Perl has been documented using perldoc.
  • Any new JavaScript has been documented using JSDoc.
  • Any new legacy JavaScript has been moved from /js to /js/source/legacy.

[bellerbrock]

The implementation looks good. The extra time needed for the store germplasm method might be a frustration in larger dbs though. A materialized stockprop refresh takes about two minutes in Cassavabase.

[timparsons]

The implementation looks good. The extra time needed for the store germplasm method might be a frustration in larger dbs though. A materialized stockprop refresh takes about two minutes in Cassavabase.

@bellerbrock Yes, agreed. With having the refresh be asynchronous, we found consistency issues due to the view still refreshing while trying to fetch data. Utilizing the synchronous call does mean longer wait time to complete the request, but the data is immediately available from the view. The larger problem to solve may be the materialized views themselves.