Follow-up to #2485385: Move highwater field support to the source plugin, and do not expose its internals on MigrationInterface
Problem/Motivation
Per alexpott's comment:
Whilst reviewing this patch I pondered if we could set the highwater properly during rollback (see #125 and #127). After thinking about @mikeryan's response some more I think we should more the NULL setting from postRollback() to preRollback() this means that is the rollback fatals for any reason then the highwater is correctly indeterminate rather than wrong.
Good point - worst-case scenario setting it in preRollback(), you have to reimport everything if rollback fails. Worst-case scenario in postRollback() (as it is now), reimporting misses anything that was successfully rolledback - i.e., data loss.
Proposed resolution
Move the highwater code in SourcePluginBase from postRollback() to preRollback().
Remaining tasks
Implement the solution (Novice task).
Tests?
User interface changes
N/A
API changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2800715-4.patch | 823 bytes | shashikant_chauhan |
Issue fork drupal-2800715
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
juancasantito commentedWaiting on #2485385: Move highwater field support to the source plugin, and do not expose its internals on MigrationInterface before working on this.
Comment #3
heddnnot postponed any longer.
Comment #4
shashikant_chauhan commentedadding patch.
Comment #5
mikeryanPatch looks good, thanks!
Next step is a test (with a test-only patch to demonstrate what we're fixing). Probably not a novice task:
Without the fix, records that were successfully rolled back before the interruption will not be imported. With it, we should get the full count back.
Comment #16
quietone commentedThis is a bugsmash target issue today. This is still valid and the starting point is still to add tests.
Comment #20
dcam commentedI didn't follow the recommended test plan. I created a unit test instead. Let me know if that isn't acceptable.
Comment #21
smustgrave commentedShows the test coverage is there.
Migration is not my best but going off @quietone in #16 mentioning this is still valid as a migration maintainer.
Solution matches the MR
Believe this one is good, but if wrong I apologize.
Comment #22
alexpottBackported to 11.1.x as a bug fix.
Committed and pushed 420f7b2ff2d to 11.x and 180597712ad to 11.2.x and a94e3c35cb7 to 11.1.x. Thanks!
Comment #26
alexpott