Upgrade from 1.7.0 to 2.0.0 results in error

[upats]

I'm attempting to upgrade from moodle 3.2 to 3.4, including quickmail from 1.7.0 (2017062200) -> 2.0.0 (2018051100) and am getting the following error:

PHP Notice:  Undefined property: stdClass::$userid in /var/www/html/moodle34/blocks/quickmail/db/upgrade.php on line 481

Notice: Undefined property: stdClass::$userid in /var/www/html/moodle34/blocks/quickmail/db/upgrade.php on line 481
Default exception handler: Error writing to database Debug: Column 'user_id' cannot be null
UPDATE mdl_block_quickmail_signatures SET title = ?,signature = ?,default_flag = ?,user_id = ?,usermodified = ?,timecreated = ?,timemodified = ?,timedeleted = ? WHERE id=?
[array (
  0 => 'Prof. Kahn',
  1 => 'Sincerely,<p><span style="color: rgb(0, 123, 171); font-family: inherit; font-size: 1.4rem;" class="">Prof. Kahn</span><p></p><h5><span style="color: rgb(0, 0, 0); font-family: \'Helvetica Neue\', Helvetica, Arial, sans-serif; font-size: 14px; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 20px; orphans: auto; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important; background-color: rgb(255, 255, 255);"><i>" A good teacher, like a good entertainer first must hold his audience\'s attention, then he can teach his lesson".</i></span></h5><br><p></p></p>',
  2 => '1',
  3 => NULL,
  4 => '7',
  5 => '1526923938',
  6 => '1526923938',
  7 => '0',
  8 => '1',
)]
Error code: dmlwriteexception
* line 489 of /lib/dml/moodle_database.php: dml_write_exception thrown
* line 1528 of /lib/dml/mysqli_native_moodle_database.php: call to moodle_database->query_end()
* line 1560 of /lib/dml/mysqli_native_moodle_database.php: call to mysqli_native_moodle_database->update_record_raw()
* line 483 of /blocks/quickmail/db/upgrade.php: call to mysqli_native_moodle_database->update_record()
* line 1001 of /lib/upgradelib.php: call to xmldb_block_quickmail_upgrade()
* line 510 of /lib/upgradelib.php: call to upgrade_plugins_blocks()
* line 1850 of /lib/upgradelib.php: call to upgrade_plugins()
* line 181 of /admin/cli/upgrade.php: call to upgrade_noncore()

[rrusso]

Your error log shows user_id is null.

That cannot be.

Maybe there’s a database integrity issue?

Chad, care to weigh in?

[upats]

Hey Robert,

This entry in mdl_block_quickmail_signatures has a user_id set. It's the first row in the table.

[chadmazilly]

Hey there @upats

One thing I noticed it that it looks like you are attempting to upgrade to an unstable branch dev-34-n. This is a new branch of the dev-34 which is the current release candidate for Quickmail v2. So, first, I'd recommend trying to upgrade to that one.

With that said, the upgrade process should be no different and should work (though you'll get a bunch of tables that aren't used yet).

Our "master" stable branch for Quickmail v1 at this point is the dev-30 branch (apologies for the naming conventions at this point!). There have been updates to that one since your tagged 2017062200 which appears to be the version you are upgrading from.

Myself and other institutions have tested going from the latest dev-30 to the latest dev-34 with no problems.

I'd recommend first upgrading to the latest dev-30 code, then upgrade to the latest dev-34.

I'm not ruling out any bugs on our side, so I'll attempt to set up the scenario you were in and report back and patch if I find any issues.

Thanks for giving it a shot, and for the feedback.

Chad

[chadmazilly]

Oops, didn't mean to close.

[upats]

Hi Chad,

Updating to the latest dev-30 branch (2017122000) worked. The subsequent attempt to update to dev-34 (2018051100) produced the same error as reported previously :(

Seems it is not pulling the proper data from the DB since there is indeed a user_id entry. Might this have something to do with the required DB collation change to utf8mb4_unicode_ci? Doesn't seem like that would be an issue with a simple integer.

Thanks, Tony

[chadmazilly]

Tony, I'm going to close this issue now as we've come up with a different strategy for migrating any existing quickmail data from v1 to v2. Because some installations may have a large amount of block_quickmail_logs or block_quickmail_drafts records, it is not safe to assume that a web installation session would be able to handle that amount of db queries. As a result, we've removed the inline script and gone to an optional scheduled task to chip away at the data according to your needs. In fact, there is a configurable "chunk size" on the amount of records that will be attempted to be migrated in a given run of the task (which defaults to 1000). I just wanted to clear out some issues here and feel like this one has been resolved. If you do want to check out the new code I'm referencing here our release candidate branch is now develop.