v4.0.1

This patch release fixes the following problems:

• demux dependency now properly set to ^4.0.1
• The MigrationSequence interface is now exported
• There are now source maps generated, to help with debugging

v4.0.0

This release upgrades to Demux v4.

New Features

• The MassiveActionHandler now utilizes the new setup method in Demux v4 to make sure a valid Massive instance was passed to the constructor, and for running any needed initial migrations.
• New error classes have been created to replace generic inline Error instances, for better debugging and error handling capabilities.

Bug Fixes

• Due to dependencies not being locked correctly, instances of the QueryFile class from pg-promise used for migrations was not passing explicit type checks from within pg-promise, as the QueryFiles being instantiated were from a different version required by MassiveJS. This issue has now been resolved.

Breaking Changes

• The MassiveActionHandler#setupDatabase public method was removed, and its funcitonality was moved to setup (as described above). Additionally, it is no longer required that you call this method before calling handleBlock(), as handleBlock() will automatically call it if it hasn't been called before.

Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any applications related thereto. We make no representation, warranty, guarantee or undertaking in respect of the releases described herein and the related GitHub release or the EOSIO software, whether expressed or implied, and disclaim all liability that may arise from any use of the software for any purpose.

v3.0.0

This release upgrades to demux v3, which means the MassiveActionHandler now supports HandlerVersions. See the demux-js documentation for more information.

Additionally, all migrations are now managed by the MassiveActionHandler itself, utilizing the MigrationRunner internally. It is now recommended that applications do not use the MigrationRunner directly, and instead allow the MassiveActionHandler to manage all database setup and migrations (including initial migrations). This allows it to be possible to migrate the database from within the Updaters' apply methods, accessed via state.migrate(<name of MigrationSequence>). See the MassiveActionHandler documentation for more details.

Breaking Changes

MassiveActionHandler (docs)

The following public methods have been added:

• setupDatabase: This is to be used instead of calling MigrationRunner.setup(). In addition to what the MigrationRunner would normally do, it will now also run the MigrationSequence named init, if exists.
• migrate: Takes the name of the MigrationSequence to be run, which are passed in when instantiated. This method is also available in Updater.apply methods, via state.migrate

The constructor now has a different signature, adding in the following arguments:

• handlerVersions See demux-js docs.
• migrationSequences: See above.

MigrationRunner

As noted, this is no longer recommended to be used directly. It is worth mentioning that any previous Postgres databases managed with this will need to be re-indexed, as the internally used _migration and _index_state tables have changed.