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

CommentFileSizeAuthor
image.png74.08 KBdonpas

Issue fork smart_date-3443532

Command icon 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

donpas created an issue. See original summary.

donpas’s picture

Issue summary: View changes
donpas’s picture

Issue summary: View changes
donpas’s picture

Issue summary: View changes

mandclu made their first commit to this issue’s fork.

mandclu’s picture

Status: Active » Needs review

Casting the $k is 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.

donpas’s picture

It 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_date instead of source: 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"?

mandclu’s picture

Status: Needs review » Closed (works as designed)

Great, thanks for the follow-up. Is this something that should be documented?

apkwilson made their first commit to this issue’s fork.

apkwilson’s picture

Status: Closed (works as designed) » Needs review

I've run into this same issue with a D7 date_repeat field, 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, $k was value, value2, or rrule. After casting $k as (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!117 was adding the migration plugin annotation handle_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 UNTIL date of the rrule isn't being converted from D7 date format, but that's a separate issue.

mandclu’s picture

Interesting! 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.

damienmckenna’s picture

Status: Needs review » Reviewed & tested by the community

I ran into this problem with the following migration structure:

  # Date range.
  field_date:
    -
      source: field_event_instance_date
      plugin: parse_dates    

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.

mandclu’s picture

Version: 4.1.x-dev » 4.2.x-dev

  • mandclu committed 269006e6 on 4.2.x
    fix: #3443532 TypeError: Unsupported operand types: string + int in...
mandclu’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for everyone's contribution here. I have merged the annotation change.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.