Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
My personally experience with this is when filtering content types but bad data or renaming content types during the migrations could also theoretically cause this problem.
Comment | File | Size | Author |
---|---|---|---|
#5 | 2588707-5.patch | 4.38 KB | phenaproxima |
#2 | 2588707-2.patch | 4.43 KB | phenaproxima |
#2 | 2588707-2-FAIL.patch | 1.61 KB | phenaproxima |
Comments
Comment #2
phenaproximaTry these on for size.
Comment #3
neclimdulConcept looks good!
Nit, tests that don't assert anything are "risky." We can assert that a field doesn't exist or something to ensure things ran quietly but the value didn't make it.
Comment #5
phenaproximaAdded a couple of assertions.
Comment #6
neclimdulThanks
Comment #8
webchickI... could not make any heads or tails out of this issue at all. ;)
Adam explained that the problem is if Article node type migration fails, and a field attempts to be migrated later, exceptions ensue. This makes the code more defensive and avoids errors. Makes sense to me.
Since these changes are self-contained against an experimental module, I believe that makes this eligible for commit during RC. Tagging.
Committed and pushed to 8.0.x. Thanks!
Comment #10
neclimdulThat pretty much sums it up. Its also a step toward allowing content types to be skipped, or possibly renamed. Just pulling an example out of thin air that surely doesn't apply to me, if you where migrating node profiles onto user fields and didn't want to pull over the profile nodes.