Problem/Motivation
Running the drush mim command while using the parse_dates process plugin that was introduced https://www.drupal.org/project/smart_date/issues/3060042 resulted in the following error.
TypeError: Unsupported operand types: string + int in Drupal\smart_date\Plugin\migrate\process\ParseDates->transform() (line 329.
The D7 field I was trying to migrate was the D7 core date field.
The YAML structure was identical to the code example on top of the class.
Could this be resolved with a simple type cast?
Drupal: 10.2.5
Issue fork smart_date-3443532
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
donpas commentedComment #3
donpas commentedComment #4
donpas commentedComment #7
mandclu commentedCasting the
$kis definitely a good place to start. It does seem like the code is expecting numeric keys but your data has some strings, so it's possible other issues will arise, but it's worth a try.Comment #8
donpas commentedIt turns out that it was a mistake on my part. The problem was in the way I was accessing the D7 date field in the migration yaml.
I was doing
source: field_dateinstead ofsource: field_date/0/value. I found this out after adding the type casting changes and re-trying to update migration.The error msg was
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'field_smart_date_end_value' cannot be null, and so it became clear that field data was not correct.Sorry for the inconvenience, I believe the status can be set to "closed works as intended"?
Comment #9
mandclu commentedGreat, thanks for the follow-up. Is this something that should be documented?
Comment #12
apkwilson commentedI've run into this same issue with a D7
date_repeatfield, including getting the follow-up error'field_smart_date_end_value' cannot be null. While trying to handle that, I came to a different conclusion.The migration plugin is written to handle all the field values for the migrating row at once, but the migration system was passing values one by one. That meant that, rather than being a field deltas,
$kwasvalue,value2, orrrule. After casting$kas(int), the key the plugin was trying to access for the end value wasn't present - it was that very key that had been casted.The solution in
MR!117was adding the migration plugin annotationhandle_multiples, which tells the migration system to pass in all the row's field values at once. That's the input the plugin expects, and it resolved all the errors I encountered. All the instances of my repeating dates were created correctly.Any
UNTILdate of therruleisn't being converted from D7 date format, but that's a separate issue.Comment #13
mandclu commentedInteresting! It does seem like this does indeed align with how the class was written, and it seems like a "low risk" solution, but I would love to get some additional community feedback on this one before we commit the change.
Comment #14
damienmckennaI ran into this problem with the following migration structure:
This is from a D10 site to a new D10 site - the old site used a core date field, the new site is Smart Date. MR 117 resolved the problem for me.
Comment #15
mandclu commentedComment #17
mandclu commentedThanks for everyone's contribution here. I have merged the annotation change.